Elasticsearch 문서 CRUD 연산 완벽 가이드

Elasticsearch에서 문서를 생성, 조회, 수정, 삭제하는 핵심 CRUD 연산을 다룹니다. Bulk API를 통한 대량 처리와 _reindex를 활용한 데이터 마이그레이션까지 실무에서 꼭 필요한 내용을 담았습니다.

---

목차

1. 문서_인덱싱
2. 문서_조회
3. 문서_업데이트
4. 문서_삭제
5. Bulk_API_대량_처리
6. _reindex_데이터_이동

---

1. 문서 인덱싱

김개발 씨는 이번에 처음으로 Elasticsearch를 사용하는 프로젝트에 투입되었습니다. MySQL에서 INSERT 문으로 데이터를 넣던 것처럼 Elasticsearch에도 데이터를 넣어야 하는데, 도대체 어떻게 해야 할지 막막했습니다.

선배에게 물어보니 "인덱싱이라고 하는 거야"라는 답이 돌아왔습니다.

문서 인덱싱은 Elasticsearch에 새로운 문서를 저장하는 작업입니다. 마치 도서관에 새 책을 등록하고 서가에 꽂아두는 것과 같습니다.

POST 메서드는 문서 ID를 자동 생성하고, PUT 메서드는 원하는 ID를 직접 지정할 수 있습니다. 이 차이를 이해하면 상황에 맞는 방법을 선택할 수 있습니다.

다음 코드를 살펴봅시다.

// POST: 문서 ID를 Elasticsearch가 자동 생성
POST /products/_doc
{
  "name": "무선 키보드",
  "price": 89000,
  "category": "electronics",
  "created_at": "2024-01-15"
}

// PUT: 문서 ID를 직접 지정 (product_001)
PUT /products/_doc/product_001
{
  "name": "게이밍 마우스",
  "price": 65000,
  "category": "electronics",
  "created_at": "2024-01-15"
}

김개발 씨는 입사 후 첫 번째 Elasticsearch 프로젝트를 맡게 되었습니다. 지금까지 관계형 데이터베이스만 다뤄왔던 터라 모든 것이 낯설게 느껴졌습니다.

특히 "인덱싱"이라는 용어가 머릿속을 맴돌았습니다. 선배 개발자 박시니어 씨가 옆자리로 다가왔습니다.

"Elasticsearch에서 데이터를 저장하는 걸 인덱싱이라고 해요. MySQL의 INSERT와 비슷하다고 생각하면 돼요." 그렇다면 인덱싱이란 정확히 무엇일까요?

쉽게 비유하자면, 인덱싱은 마치 도서관에 새 책을 등록하는 과정과 같습니다. 책이 들어오면 고유 번호를 부여하고, 제목, 저자, 출판일 같은 정보를 기록한 뒤 적절한 서가에 배치합니다.

Elasticsearch도 마찬가지입니다. 문서가 들어오면 고유 ID를 부여하고, 내용을 분석하여 검색 가능한 형태로 저장합니다.

여기서 중요한 선택이 있습니다. POST와 PUT, 두 가지 방법 중 어떤 것을 사용할 것인가입니다.

POST 메서드를 사용하면 Elasticsearch가 알아서 고유한 문서 ID를 생성해줍니다. 마치 도서관 시스템이 자동으로 청구기호를 붙여주는 것과 같습니다.

개발자는 ID 중복 걱정 없이 데이터만 던져주면 됩니다. 반면 PUT 메서드는 개발자가 직접 ID를 지정합니다.

"이 책은 A-001번으로 하겠어"라고 명시하는 것입니다. 이미 해당 ID가 존재한다면 기존 문서를 덮어씁니다.

따라서 PUT은 생성과 전체 교체를 동시에 수행할 수 있습니다. 위의 코드를 살펴보겠습니다.

첫 번째 POST 요청은 /products/_doc 경로로 보냅니다. 여기서 products는 인덱스 이름이고, _doc은 문서 타입을 나타냅니다.

응답으로 _id 필드에 자동 생성된 ID가 담겨 돌아옵니다. 두 번째 PUT 요청은 경로 끝에 product_001이라는 ID를 명시했습니다.

이 요청이 성공하면 해당 문서는 정확히 그 ID로 저장됩니다. 나중에 이 ID만 알면 바로 문서를 찾을 수 있습니다.

실제 현업에서는 어떻게 선택할까요? 로그 데이터처럼 대량으로 쏟아지는 데이터는 POST로 자동 ID를 받는 것이 편합니다.

반면 사용자 정보처럼 외부 시스템의 ID와 맞춰야 하는 경우에는 PUT으로 ID를 직접 지정하는 것이 좋습니다. 박시니어 씨가 덧붙였습니다.

"참, PUT으로 같은 ID에 다시 요청하면 기존 문서가 통째로 교체되니까 주의해야 해요. 부분 수정은 _update를 써야 합니다." 김개발 씨는 고개를 끄덕였습니다.

INSERT와 비슷하면서도 다른, Elasticsearch만의 방식이 조금씩 이해되기 시작했습니다.

실전 팁

💡 - POST는 대량 로그 수집처럼 ID가 중요하지 않을 때 사용하세요

• PUT은 외부 시스템 ID와 동기화가 필요할 때 적합합니다
• PUT은 전체 교체이므로 부분 수정에는 _update API를 사용하세요

---

2. 문서 조회

인덱싱을 마친 김개발 씨는 이제 저장한 문서를 꺼내보고 싶었습니다. "방금 넣은 데이터가 제대로 들어갔는지 확인해봐야겠어." MySQL에서 SELECT 문으로 조회하듯이, Elasticsearch에서도 분명 방법이 있을 것입니다.

문서 조회는 저장된 문서를 ID로 직접 가져오는 작업입니다. 마치 도서관에서 청구기호를 알면 바로 그 책을 찾아올 수 있는 것과 같습니다.

GET 메서드에 인덱스 이름과 문서 ID를 지정하면 해당 문서의 전체 내용을 즉시 확인할 수 있습니다.

다음 코드를 살펴봅시다.

// 단일 문서 조회: ID로 직접 접근
GET /products/_doc/product_001

// 응답 예시
{
  "_index": "products",
  "_id": "product_001",
  "_version": 1,
  "_source": {
    "name": "게이밍 마우스",
    "price": 65000,
    "category": "electronics"
  }
}

// 특정 필드만 조회: _source_includes 파라미터 활용
GET /products/_doc/product_001?_source_includes=name,price

김개발 씨는 방금 인덱싱한 문서가 제대로 저장되었는지 확인하고 싶었습니다. 눈으로 직접 봐야 안심이 되는 성격이었습니다.

박시니어 씨가 화면을 가리키며 말했습니다. "GET 요청 하나면 돼요.

인덱스 이름이랑 문서 ID만 알면 바로 꺼내볼 수 있어요." 문서 조회는 Elasticsearch에서 가장 빠른 데이터 접근 방법입니다. 검색과는 다릅니다.

검색은 조건에 맞는 문서를 찾아내는 것이고, 조회는 이미 ID를 알고 있는 문서를 직접 가져오는 것입니다. 비유하자면, 도서관에서 "경제학 관련 책 추천해주세요"라고 요청하는 것이 검색이라면, "A-001번 책 가져다 주세요"라고 요청하는 것이 조회입니다.

당연히 후자가 훨씬 빠릅니다. GET 요청의 구조는 단순합니다.

/인덱스명/_doc/문서ID 형태로 경로를 구성하면 됩니다. 위 코드에서 /products/_doc/product_001은 products 인덱스에서 product_001이라는 ID를 가진 문서를 달라는 뜻입니다.

응답을 살펴보면 몇 가지 메타데이터가 함께 옵니다. _index는 문서가 속한 인덱스 이름, _id는 문서의 고유 식별자, _version은 문서가 몇 번 수정되었는지를 나타냅니다.

그리고 가장 중요한 _source 필드에 실제 문서 내용이 담겨 있습니다. 여기서 한 가지 꿀팁이 있습니다.

문서에 필드가 수십 개인데 그중 두세 개만 필요하다면 어떻게 할까요? 전체를 가져와서 애플리케이션에서 필터링하는 것은 비효율적입니다.

이럴 때 _source_includes 파라미터를 사용합니다. 위 코드의 마지막 예시처럼 필요한 필드명을 콤마로 나열하면 해당 필드만 응답에 포함됩니다.

네트워크 비용도 줄이고 처리 속도도 빨라집니다. 반대로 특정 필드만 제외하고 싶다면 _source_excludes를 사용하면 됩니다.

상황에 맞게 선택하면 됩니다. 실무에서 문서 조회는 주로 상세 페이지 구현에 활용됩니다.

상품 목록에서 특정 상품을 클릭했을 때, 해당 상품의 ID로 문서를 조회하여 상세 정보를 보여주는 식입니다. 김개발 씨가 GET 요청을 실행하자 방금 저장한 게이밍 마우스 정보가 화면에 나타났습니다.

"오, 진짜 들어가 있네요!" 눈으로 확인하니 한결 마음이 놓였습니다.

실전 팁

💡 - 문서 조회는 검색보다 훨씬 빠르므로 ID를 알 때는 GET을 사용하세요

• _source_includes로 필요한 필드만 가져오면 성능이 향상됩니다
• 문서가 존재하지 않으면 404 응답이 반환됩니다

---

3. 문서 업데이트

다음 날, 김개발 씨에게 급한 요청이 들어왔습니다. "어제 등록한 게이밍 마우스 가격이 잘못 들어갔대요.

65,000원이 아니라 59,000원이래요." 전체 문서를 다시 PUT으로 덮어써야 할까요? 가격 하나 바꾸자고 모든 필드를 다시 보내는 건 너무 번거로워 보였습니다.

_update API는 문서의 일부 필드만 수정할 때 사용합니다. 마치 책의 오탈자를 수정할 때 해당 페이지만 고치는 것과 같습니다.

전체 문서를 다시 보낼 필요 없이 변경할 필드만 지정하면 되므로 네트워크 비용과 실수 가능성을 줄일 수 있습니다.

다음 코드를 살펴봅시다.

// 특정 필드만 업데이트: doc 파라미터 사용
POST /products/_update/product_001
{
  "doc": {
    "price": 59000,
    "updated_at": "2024-01-16"
  }
}

// 스크립트로 업데이트: 기존 값을 기반으로 계산
POST /products/_update/product_001
{
  "script": {
    "source": "ctx._source.price = ctx._source.price * 0.9",
    "lang": "painless"
  }
}

// upsert: 문서가 없으면 생성, 있으면 업데이트
POST /products/_update/product_001
{
  "doc": { "stock": 100 },
  "upsert": { "name": "새 상품", "stock": 100 }
}

김개발 씨는 난감했습니다. 가격 하나 고치자고 상품명, 카테고리, 등록일까지 모든 필드를 다시 보내야 한다면 너무 비효율적입니다.

게다가 실수로 다른 필드를 빠뜨리면 데이터가 유실될 수도 있습니다. 박시니어 씨가 해결책을 알려주었습니다.

"_update API를 쓰면 돼요. 바꿀 필드만 보내면 나머지는 그대로 유지됩니다." _update API는 부분 수정의 달인입니다.

PUT이 문서 전체를 교체하는 것과 달리, _update는 기존 문서를 읽어와서 지정한 필드만 병합한 후 다시 저장합니다. 내부적으로는 읽기-수정-쓰기 과정이 일어나지만, 개발자는 변경할 내용만 신경 쓰면 됩니다.

첫 번째 코드 예시를 보겠습니다. doc 파라미터 안에 수정할 필드만 넣으면 됩니다.

가격을 59,000원으로 바꾸고 수정일도 함께 업데이트했습니다. 나머지 필드인 name, category 등은 건드리지 않아도 그대로 유지됩니다.

두 번째 예시는 더 강력합니다. 스크립트를 사용하면 기존 값을 기반으로 계산할 수 있습니다.

"현재 가격에서 10% 할인"처럼 상대적인 변경이 가능합니다. Elasticsearch는 Painless라는 자체 스크립트 언어를 사용합니다.

ctx._source는 현재 문서를 가리키고, 거기에 원하는 연산을 적용하면 됩니다. 세 번째 예시는 실무에서 정말 유용한 패턴입니다.

upsert는 update와 insert를 합친 말입니다. 문서가 이미 존재하면 doc 내용으로 업데이트하고, 존재하지 않으면 upsert 내용으로 새로 생성합니다.

조회하고 없으면 생성하는 로직을 한 번의 요청으로 처리할 수 있습니다. 주의할 점도 있습니다.

_update는 내부적으로 문서를 읽고 수정하고 다시 쓰는 과정을 거칩니다. 따라서 동시에 여러 요청이 같은 문서를 수정하려 하면 충돌이 발생할 수 있습니다.

이럴 때는 retry_on_conflict 파라미터로 재시도 횟수를 지정할 수 있습니다. 김개발 씨는 _update API로 가격만 깔끔하게 수정했습니다.

"PUT으로 전체를 덮어쓸 뻔했는데, 위험할 뻔했네요." 부분 수정의 중요성을 몸소 느낀 순간이었습니다.

실전 팁

💡 - 단순 필드 수정은 doc 파라미터, 계산이 필요하면 script를 사용하세요

• upsert를 활용하면 존재 여부 체크 없이 한 번에 처리할 수 있습니다
• 동시성 이슈가 예상되면 retry_on_conflict 옵션을 추가하세요

---

4. 문서 삭제

며칠 후, 운영팀에서 연락이 왔습니다. "테스트로 등록했던 상품들 좀 삭제해주세요.

실서비스에 노출되면 안 돼요." 김개발 씨는 삭제 방법을 찾아보기 시작했습니다. 생성과 수정만큼이나 삭제도 중요한 작업이니까요.

DELETE API는 문서를 인덱스에서 제거합니다. 마치 도서관에서 더 이상 필요 없는 책을 폐기하는 것과 같습니다.

문서 ID를 지정하여 단일 문서를 삭제하거나, 쿼리를 사용해 조건에 맞는 여러 문서를 한 번에 삭제할 수 있습니다.

다음 코드를 살펴봅시다.

// 단일 문서 삭제: ID로 직접 지정
DELETE /products/_doc/product_001

// 쿼리로 조건에 맞는 문서 일괄 삭제
POST /products/_delete_by_query
{
  "query": {
    "term": {
      "category": "test"
    }
  }
}

// 삭제 확인: 문서 존재 여부 체크
HEAD /products/_doc/product_001
// 200: 존재함, 404: 삭제됨

김개발 씨는 삭제 작업이 조금 긴장되었습니다. 잘못 삭제하면 복구가 어렵기 때문입니다.

하지만 테스트 데이터가 실서비스에 노출되는 것은 더 큰 문제였습니다. 박시니어 씨가 조언했습니다.

"삭제 전에 꼭 대상을 한번 확인해보세요. 그리고 가능하면 개별 삭제보다 조건 삭제를 권장해요.

더 안전하거든요." DELETE API의 기본 사용법은 간단합니다. DELETE 메서드에 인덱스명과 문서 ID를 지정하면 끝입니다.

첫 번째 코드 예시처럼 /products/_doc/product_001로 요청하면 해당 문서가 삭제됩니다. 하지만 실무에서는 하나씩 삭제하는 경우가 드뭅니다.

보통 "카테고리가 test인 문서를 모두 삭제해주세요"처럼 조건부 삭제가 필요합니다. 이때 _delete_by_query API를 사용합니다.

두 번째 코드를 보면, POST 메서드로 /products/_delete_by_query 경로에 쿼리를 보냅니다. query 안에 삭제 조건을 지정하면 해당 조건에 맞는 모든 문서가 삭제됩니다.

위 예시에서는 category 필드가 "test"인 문서들이 대상입니다. 삭제가 제대로 되었는지 확인하고 싶다면 HEAD 메서드를 활용합니다.

HEAD는 문서 내용은 가져오지 않고 존재 여부만 확인합니다. 200 응답이면 아직 존재하고, 404 응답이면 삭제된 것입니다.

여기서 중요한 점이 있습니다. Elasticsearch에서 삭제된 문서는 즉시 디스크에서 사라지지 않습니다.

내부적으로 "삭제됨"이라고 표시만 해두고, 나중에 세그먼트 병합 과정에서 실제로 제거됩니다. 따라서 대량 삭제 직후에는 디스크 공간이 바로 늘어나지 않을 수 있습니다.

또한 _delete_by_query는 실행 중에 새로 인덱싱되는 문서는 삭제하지 않습니다. 시작 시점의 스냅샷을 기준으로 동작하기 때문입니다.

지속적으로 데이터가 들어오는 환경에서는 이 점을 고려해야 합니다. 김개발 씨는 먼저 검색 쿼리로 삭제 대상을 확인한 후, 같은 쿼리를 _delete_by_query에 적용했습니다.

테스트 상품들이 깔끔하게 정리되었습니다. "휴, 실수 없이 끝나서 다행이야."

실전 팁

💡 - 삭제 전 반드시 동일한 쿼리로 대상 문서를 먼저 검색해서 확인하세요

• _delete_by_query는 대량 작업이므로 운영 환경에서는 부하를 고려하세요
• 삭제된 데이터 복구는 어려우니 중요 데이터는 백업 후 진행하세요

---

5. Bulk API 대량 처리

다음 주, 대규모 데이터 마이그레이션 프로젝트가 시작되었습니다. 기존 시스템에서 10만 건의 상품 데이터를 Elasticsearch로 옮겨야 합니다.

김개발 씨는 처음에 for문으로 하나씩 인덱싱하는 코드를 작성했습니다. 하지만 예상 소요 시간을 계산해보니 아찔했습니다.

Bulk API는 여러 문서 작업을 한 번의 요청으로 처리합니다. 마치 택배를 한 박스에 여러 개 담아 보내는 것과 같습니다.

네트워크 왕복을 줄여 대량 데이터 처리 성능을 극적으로 향상시킵니다. 인덱싱, 업데이트, 삭제를 하나의 요청에 섞어서 보낼 수도 있습니다.

다음 코드를 살펴봅시다.

// Bulk API: 여러 작업을 한 번에 처리
POST /_bulk
{"index": {"_index": "products", "_id": "p001"}}
{"name": "노트북", "price": 1500000, "category": "electronics"}
{"index": {"_index": "products", "_id": "p002"}}
{"name": "모니터", "price": 350000, "category": "electronics"}
{"update": {"_index": "products", "_id": "p001"}}
{"doc": {"price": 1400000}}
{"delete": {"_index": "products", "_id": "old_product"}}

// Node.js에서 Bulk API 활용
const body = products.flatMap(doc => [
  { index: { _index: 'products', _id: doc.id } },
  doc
]);
await client.bulk({ refresh: true, body });

김개발 씨의 첫 번째 시도는 단순했습니다. 10만 건의 데이터를 반복문으로 돌면서 하나씩 인덱싱하는 것이었습니다.

테스트로 1,000건을 돌려보니 약 3분이 걸렸습니다. 단순 계산으로 10만 건이면 5시간입니다.

박시니어 씨가 코드를 보더니 고개를 저었습니다. "그렇게 하면 네트워크 왕복만 10만 번이에요.

Bulk API를 써야 해요." Bulk API는 대량 작업의 핵심입니다. 개별 요청을 보내면 요청-응답-요청-응답의 반복으로 네트워크 오버헤드가 쌓입니다.

반면 Bulk API는 수백, 수천 개의 작업을 하나의 요청에 담아 보냅니다. 비유하자면, 편지 100통을 보낼 때 우체국에 100번 가는 것과 한 번에 모아서 가는 것의 차이입니다.

당연히 후자가 효율적입니다. Bulk API의 형식은 독특합니다.

NDJSON이라고 부르는 줄바꿈으로 구분된 JSON 형식을 사용합니다. 첫 번째 줄은 작업 유형과 메타데이터, 다음 줄은 실제 데이터입니다.

이 쌍이 반복됩니다. 위 코드를 분석해보겠습니다.

index 작업은 문서를 인덱싱합니다. _index와 _id를 지정하고, 다음 줄에 문서 내용을 넣습니다.

update 작업은 부분 수정으로, doc 필드에 변경 내용을 담습니다. delete 작업은 삭제할 문서의 메타데이터만 있고 다음 줄이 없습니다.

이렇게 서로 다른 작업을 하나의 요청에 섞을 수 있다는 점이 강력합니다. 인덱싱 중간에 삭제도 하고 업데이트도 하는 복잡한 시나리오를 단일 요청으로 처리할 수 있습니다.

실무에서 권장하는 배치 크기는 보통 1,000건에서 5,000건 사이입니다. 너무 작으면 네트워크 오버헤드가 크고, 너무 크면 메모리 부담이 생깁니다.

정확한 최적값은 문서 크기와 클러스터 사양에 따라 다르므로 테스트로 찾아야 합니다. 김개발 씨가 Bulk API로 코드를 수정하고 다시 돌렸습니다.

10만 건 처리에 3분이 채 걸리지 않았습니다. "5시간이 3분으로?

이게 이렇게 차이가 나는 거였어?" 대량 데이터 처리에서 Bulk API가 왜 필수인지 체감한 순간이었습니다.

실전 팁

💡 - 배치 크기는 1,000~5,000건 사이에서 테스트하며 최적값을 찾으세요

• Bulk 응답에서 errors 필드를 확인하여 실패한 항목을 처리하세요
• refresh 옵션은 꼭 필요할 때만 사용하세요, 성능에 영향을 줍니다

---

6. reindex 데이터 이동

한 달 후, 인덱스 설계를 변경해야 하는 상황이 발생했습니다. 기존 products 인덱스의 매핑을 바꿔야 하는데, Elasticsearch는 이미 생성된 필드의 매핑을 변경할 수 없습니다.

"새 인덱스를 만들고 데이터를 옮겨야 해요." 박시니어 씨의 말에 김개발 씨는 Bulk API로 일일이 옮겨야 하나 걱정되었습니다.

_reindex API는 한 인덱스의 문서를 다른 인덱스로 복사합니다. 마치 도서관의 책들을 새 건물로 이사할 때 자동화된 시스템으로 옮기는 것과 같습니다.

매핑 변경, 인덱스 통합, 데이터 변환 등 다양한 시나리오에서 활용됩니다. 복사 과정에서 스크립트로 데이터를 가공할 수도 있습니다.

다음 코드를 살펴봅시다.

// 기본 reindex: 소스 인덱스에서 대상 인덱스로 복사
POST /_reindex
{
  "source": { "index": "products" },
  "dest": { "index": "products_v2" }
}

// 조건부 reindex: 특정 문서만 선택적으로 이동
POST /_reindex
{
  "source": {
    "index": "products",
    "query": { "term": { "category": "electronics" } }
  },
  "dest": { "index": "electronics_products" }
}

// 스크립트로 데이터 변환하며 reindex
POST /_reindex
{
  "source": { "index": "products" },
  "dest": { "index": "products_v2" },
  "script": {
    "source": "ctx._source.price_with_tax = ctx._source.price * 1.1"
  }
}

김개발 씨는 걱정이 앞섰습니다. 100만 건이 넘는 상품 데이터를 새 인덱스로 옮겨야 하는데, Bulk API로 직접 코드를 작성하려면 시간이 많이 걸릴 것 같았습니다.

박시니어 씨가 말했습니다. "_reindex API가 있어요.

한 줄 명령으로 인덱스 전체를 복사할 수 있습니다." _reindex API는 인덱스 마이그레이션의 핵심 도구입니다. 내부적으로 소스 인덱스를 스캔하여 대상 인덱스로 Bulk 인덱싱을 수행합니다.

개발자가 직접 데이터를 읽고 쓰는 코드를 작성할 필요가 없습니다. 첫 번째 코드 예시는 가장 기본적인 형태입니다.

source에 원본 인덱스, dest에 대상 인덱스를 지정하면 모든 문서가 복사됩니다. 대상 인덱스가 없으면 자동으로 생성되지만, 매핑을 미리 정의해두는 것이 좋습니다.

두 번째 예시는 조건부 복사입니다. source 안에 query를 추가하면 해당 조건에 맞는 문서만 복사됩니다.

위 예시에서는 카테고리가 electronics인 상품만 새 인덱스로 옮깁니다. 대규모 인덱스를 여러 개의 작은 인덱스로 분리할 때 유용합니다.

세 번째 예시가 가장 강력합니다. 스크립트를 사용하면 복사하면서 동시에 데이터를 변환할 수 있습니다.

위 코드는 복사 과정에서 price_with_tax라는 새 필드를 계산하여 추가합니다. 기존 데이터에 새로운 필드를 일괄 추가해야 할 때 매우 효율적입니다.

_reindex는 기본적으로 동기 방식으로 동작합니다. 데이터가 많으면 시간이 오래 걸리고 타임아웃이 발생할 수 있습니다.

이런 경우 wait_for_completion=false 옵션을 추가하면 백그라운드에서 비동기로 실행됩니다. task API로 진행 상황을 모니터링할 수 있습니다.

또한 소스 인덱스에 계속 데이터가 들어오는 상황이라면, reindex 완료 후 누락된 데이터를 추가로 동기화해야 합니다. 완벽한 무중단 마이그레이션을 위해서는 alias를 활용한 전략이 필요합니다.

김개발 씨는 새 인덱스의 매핑을 먼저 생성하고, _reindex로 데이터를 복사했습니다. 100만 건이 약 10분 만에 새 인덱스로 이동했습니다.

"이렇게 편한 방법이 있었다니!" 인덱스 마이그레이션에 대한 두려움이 사라지는 순간이었습니다.

실전 팁

💡 - 대상 인덱스의 매핑은 미리 정의해두는 것이 좋습니다

• 대량 데이터는 wait_for_completion=false로 비동기 실행하세요
• 운영 환경에서는 slices 옵션으로 병렬 처리하면 속도가 빨라집니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!