Belajar Elasticsearch - Reindex & Update By Query Operations

#Pendahuluan

Mengubah mapping (episode 5) atau analyzer (episode 7) tidak bisa diterapkan ke dokumen yang sudah terindeks. Field yang salah tipe, analyzer baru, atau format yang berubah — semuanya menuntut membangun ulang data. Beruntung Elasticsearch menyediakan Reindex API dan Update By Query.

Episode 13 membahas kapan perlu reindex, Reindex API dengan filter dan script, reindex dari remote cluster, Update By Query untuk mass update, Delete By Query, serta penanganan konflik versi dan throttling.## Kapan Perlu Reindex

Reindex adalah proses menyalin dokumen dari index sumber ke index target dengan mapping/settings baru. Ini diperlukan ketika:

• Jumlah primary shards perlu diubah (tidak bisa diubah langsung).
• Mapping perlu diperbaiki — misalnya field yang salah text/keyword.
• Analyzer berubah dan dokumen lama perlu di-analisis ulang.
• Field perlu digabung, dipecah, atau dihilangkan lewat script.
• Index perlu dipindahkan antar cluster atau antar tier.

Pola terbaiknya selalu sama: buat index baru dengan mapping benar, reindex, lalu pindahkan alias (episode 4) dari index lama ke index baru — aplikasi tidak pernah berhenti.

#Reindex API Dasar

POST /_reindex
{
  "source": { "index": "produk" },
  "dest": { "index": "produk-v2" }
}

dest harus sudah ada (atau dibuat otomatis dengan dynamic mapping — lebih baik dibuat eksplisit lebih dulu dengan mapping target). Untuk menjaga sumber tetap hidup selama proses, set "dest": { "index": "produk-v2", "version_type": "external" } agar dokumen sumber yang berubah selama reindex tidak konflik.

#Reindex dengan Query Filter dan Script

Tidak semua data harus dipindahkan — kadang cukup subset, dan sering kali perlu transformasi. Keduanya bisa digabung dalam satu request:

{
  "source": {
    "index": "produk",
    "query": {
      "term": { "category.keyword": "fashion" }
    }
  },
  "dest": { "index": "produk-v2" },
  "script": {
    "source": "ctx._source.price_diskon = ctx._source.price * 0.9"
  }
}

Script Painless di atas menambahkan field price_diskon ke setiap dokumen yang dipindahkan. Query memfilter dokumen yang masuk — hanya produk fashion yang ikut reindex. Kombinasi filter + script membuat reindex sangat fleksibel.

#Bekerja Asinkron

Reindex data besar bukan proses instan. Defaultnya request _reindex berjalan sinkron dan bisa timeout untuk dataset besar — untuk production, jalankan asinkron dengan ?wait_for_completion=false:

POST /_reindex?wait_for_completion=false
GET /_tasks/<task_id>?pretty

Respons pertama mengembalikan task_id; _tasks lalu menunjukkan jumlah dokumen yang berhasil dan yang gagal. Ini pola standar untuk reindex jutaan dokumen.

#Reindex dari Remote Cluster

Reindex juga bisa menarik data dari cluster lain — misalnya memigrasi data dari Elasticsearch lama (versi 7.x) ke cluster 8.x baru. Sumber diatur sebagai remote cluster:

POST /_reindex
{
  "source": {
    "remote": {
      "host": "https://old-cluster:9200",
      "username": "migration",
      "password": "secret"
    },
    "index": "produk"
  },
  "dest": { "index": "produk-v2" }
}

Perhatikan: klausa query pada sumber remote tidak didukung (dibatasi), sehingga pemfilteran data sebaiknya dilakukan setelah data masuk. Reindex remote juga wajib menggunakan koneksi HTTPS (episode 16) dan remote_cluster_client role pada node.

#Update By Query

Update By Query mengubah dokumen yang cocok dengan query di tempatnya, tanpa membuat index baru. Ini bedanya dengan reindex: tidak ada penyalinan ke index lain. Contoh: menambahkan field ke semua dokumen log lama:

POST /produk/_update_by_query
{
  "query": {
    "term": { "category.keyword": "fashion" }
  },
  "script": {
    "source": "ctx._source.price = ctx._source.price * 0.85"
  }
}

Update By Query menjalankan pencarian + update dalam satu operasi dan juga bisa berjalan asinkron dengan ?wait_for_completion=false. Ini solusi tercepat untuk transformasi yang tidak perlu mengubah mapping.

#Delete By Query

Kebalikannya: Delete By Query menghapus dokumen yang cocok dengan query tanpa menghapus index:

POST /logs-2026.07/_delete_by_query
{
  "query": {
    "range": {
      "@timestamp": { "lte": "2026-07-01T00:00:00Z" }
    }
  }
}

Dokumen yang dihapus tidak langsung hilang dari disk — penandaan hapus terjadi di segment, dan ruangnya baru dibebaskan saat merge (episode 2). Untuk membersihkan storage besar, pertimbangkan force merge setelah delete by query.

#Konflik dan Throttling

#Konflik Versi

Selama reindex/update berjalan, dokumen bisa berubah oleh operasi lain — menyisakan version conflict (409). Dua strategi penanganan: version_type: external pada reindex (versi sumber dipertahankan) dan "conflicts": "proceed" (lewati dokumen konflik):

POST /_reindex
{
  "source": { "index": "produk" },
  "dest": { "index": "produk-v2", "version_type": "external" },
  "conflicts": "proceed"
}

#Throttling

Operasi massal memakai resource cluster; membiarkannya berjalan bebas bisa membuat layanan lain kelaparan. Batasi kecepatan dengan requests_per_second — misalnya 1000 request per detik:

POST /_reindex
{
  "source": { "index": "produk" },
  "dest": { "index": "produk-v2" },
  "conflicts": "proceed",
  "requests_per_second": 1000
}

Throttle sangat berguna saat reindex berjalan di samping lalu lintas produksi — lebih lambat di siang hari, lebih cepat di malam hari.

#Kesalahan Umum

1. Lupa ?wait_for_completion=false untuk data besar. Request sinkron bisa timeout — jadikan asinkron dan pantau task.
2. Reindex tanpa mapping target eksplisit. Dynamic mapping di index target bisa menghasilkan mapping yang sama salahnya.
3. Melupakan alias. Setelah reindex, aplikasi yang menunjuk index lama tidak otomatis ikut — pindahkan alias sebagai langkah akhir.
4. Update by query tanpa konfigurasi konflik. Operasi paralel menghasilkan 409 — atur conflicts: proceed bila aman.
5. Tanpa throttling di cluster sibuk. Reindex penuh bisa memicu circuit breaker — batasi kecepatan.

#Penutup

Di episode 13 kalian menguasai operasi massal: kapan perlu reindex, Reindex API dengan query filter dan script, reindex asinkron dengan task tracking, reindex dari remote cluster, Update By Query, Delete By Query, serta penanganan konflik versi dan throttling.

Inti yang harus dibawa pulang:

• Reindex untuk mengubah mapping/shard/analyzer; buat index baru, salin, pindah alias.
• Reindex bisa berjalan asinkron dengan wait_for_completion=false dan dipantau lewat Tasks API.
• Update By Query mengubah dokumen di tempat; Delete By Query menghapus yang cocok.
• Tangani konflik versi dengan version_type: external dan conflicts: proceed; gunakan throttling (requests_per_second) agar cluster aman.

Semua operasi sejauh ini terjadi di satu instance. Tapi Elasticsearch sejati hidup sebagai cluster. Di episode 14 kita bahas cluster configuration dan node management: static vs dynamic settings, discovery dan cluster formation, node roles, JVM heap sizing, thread pools, dan circuit breakers. Sampai jumpa!