Belajar Elasticsearch - Performance Optimization & Tuning

#Pendahuluan

Elasticsearch cepat bukan karena sihir — kecepatan adalah hasil dari serangkaian trade-off yang diatur dengan benar. Data yang masuk tanpa henti, pencarian yang harus menjawab dalam milidetik, dan resource yang terbatas menuntut kalian paham mana yang perlu di-tune dan mana yang biarkan default.

Episode 19 membahas tiga wilayah tuning: indexing performance (bulk, refresh interval, translog, replica saat indexing, index sorting), search performance (optimasi query, caching, filter, jumlah shard, routing), dan resource optimization (JVM G1GC, disk I/O, memory pressure, thread pool).

#Indexing Performance

#Bulk Indexing

Aturan pertama indexing cepat: selalu pakai bulk API (episode 4). Jangan pernah mengirim dokumen satu per satu. Konfigurasikan ukuran batch yang tepat:

POST /produk/_bulk
{ "index": { "_id": "1" } }
{ "name": "produk 1", "price": 50000 }
{ "index": { "_id": "2" } }
{ "name": "produk 2", "price": 75000 }

Bulk yang ideal berisi 1–10 ribu dokumen atau total 5–15 MB, lalu coba naikkan bertahap sambil memantau took. Ukuran optimal bergantung hardware — jangan menyalin angka dari tutorial tanpa mengukur sendiri.

#Refresh Interval

Data yang diindeks baru terlihat setelah refresh (default 1 detik). Untuk beban indexing massal, refresh setiap detik berarti banyak pekerjaan sinkronisasi segment. Untuk saat ini naikkan interval agar indexing jauh lebih cepat:

PUT /produk/_settings

{
  "index.refresh_interval": "30s"
}

Setelah loading selesai, kembalikan ke 1s (atau otomatis). Pengecualian: aplikasi yang butuh hasil search instan tidak boleh menaikkan interval ini sembarangan — ingat trade-off near-real-time di episode 2.

#Translog

Translog (episode 2) menjamin keamanan tulis sebelum data tersegmentasi. Pengaturan durability punya dua mode:

{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "5s"
}

Mode request (default) mem-flush translog ke disk per request — paling aman, tapi lambat untuk load massal. Mode async mempercepat indexing dengan risiko kehilangan data beberapa detik terakhir jika node crash. Gunakan async hanya untuk indexing massal di mana data bisa di-re-index ulang; untuk data penting, tetap request.

#Replica Selama Indexing

Replica memperlambat indexing karena setiap tulis disalin. Untuk loading massal, set replica ke 0 saat load, lalu naikkan kembali setelah selesai:

{
  "index.number_of_replicas": 0
}

Setelah selesai, kembalikan ke 1: PUT /produk/_settings dengan {"index.number_of_replicas": 1}. Ini trik klasik yang memangkas waktu load besar secara signifikan.

#Index Sorting

Index sorting mengatur urutan penyimpanan dokumen di dalam segment. Jika pencarian kalian sering di-sort atau difilter oleh field tertentu — misalnya @timestamp — urutkan index berdasarkan field itu agar query rentang waktu jadi jauh lebih efisien:

{
  "settings": {
    "index.sort.field": "@timestamp",
    "index.sort.order": "desc"
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" }
    }
  }
}

Index sorting hanya bisa diatur saat pembuatan index — perhatikan sejak awal. Trade-off-nya: indexing sedikit lebih mahal, tapi range query dan top-N jauh lebih cepat.

#Search Performance

#Optimasi Query

Prinsip optimasi query:

• Gunakan filter, bukan query, untuk kriteria ya/tidak — hasilnya di-cache (episode 8).
• Batasi field yang di-scroll dengan _source filtering dan stored_fields.
• Gunakan search_after, bukan from yang besar (episode 6).
• Hindari wildcard di awal pola (*foo) yang memaksa pemindaian istilah.

#Caching: Tiga Lapisan

Request cache bekerja per shard dan batal jika ada dokumen baru — jadi efektif untuk data jarang berubah. Field data cache menahan struktur di memori; pastikan field yang di-aggregate bertipe keyword/numerik dan jarang berubah.

#Jumlah Shard dan Routing

Jumlah shard yang tepat (10–50 GB per shard, episode 18) memengaruhi latency search — setiap shard menambah biaya komunikasi. Pre-filtering dengan routing membatasi pencarian ke subset shard:

GET /produk/_search?routing=fashion

Saat aplikasi sudah tahu kategori target, routing menghemat waktu pencarian drastis.

#Resource Optimization

#JVM dan G1GC

G1GC adalah GC default di Elasticsearch 8.x — dirancang untuk heap besar dengan pause terkendali:

-Xms8g
-Xmx8g
-XX:+UseG1GC
-XX:G1HeapRegionSize=4m
-XX:MaxGCPauseMillis=500

Pemantauan GC adalah sinyal paling penting: pause panjang dan promotion failed menandakan masalah. Episode 21 akan membahas metrik JVM secara detail.

#Disk I/O

Indexing dan merge adalah pekerjaan berat I/O. Pastikan: segment merge berjalan di background yang terjadwal (index.merge.scheduler.max_thread_count), dan jangan memaksa merge saat load indexing. SSD untuk tier hot (episode 18) adalah investasi yang terbayar.

#Memory Pressure

Memory pressure mengukur beban heap terhadap kapasitas. Jika tekanan tinggi dan RejectedExecutionException sering muncul, solusinya bukan mengubah konfigurasi — tapi menambah node atau memperbaiki query/aggregation yang boros.

#Kesalahan Umum

1. Bulk yang dihapal tanpa pengukuran. Ukuran batch optimal bergantung hardware — ukur dengan took dan iterasi.

2. Refresh interval 1s di load massal. Perlambat dulu, kembalikan setelahnya.

3. Replica 1 saat load besar. Set 0 saat load, kembalikan setelah selesai.

4. from besar untuk pagination. Gunakan search_after.

5. Index sorting diterapkan terlambat. Harus dari awal — rancang di mapping pertama.

#Penutup

Di episode 19 kalian menguasai performance tuning: bulk indexing dengan batch terukur, refresh interval dan translog async untuk load massal, replica nol saat loading, index sorting; optimasi search dengan filter/caching/routing dan search_after; serta resource tuning G1GC, disk I/O, dan pemantauan memory pressure.

Inti yang harus dibawa pulang:

• Bulk selalu — ukur ukuran batch, jangan menebak.
• Refresh dan translog adalah trade-off kecepatan vs keamanan data.
• Replica 0 saat load, 1 setelahnya — trik paling efektif untuk indexing massal.
• Filter di-cache, request cache rentan invalidasi — gunakan sesuai jenis data.
• Tuning yang baik terukur dan iteratif, bukan menyalin konfigurasi.

Performanya sudah optimal — tapi satu insiden disk rusak bisa menghapus semuanya. Di episode 20 kita bahas snapshot dan restore sebagai strategi backup: jenis repository (filesystem, S3, GCS, Azure), snapshot lifecycle management (SLM), snapshot penuh dan incremental, pemulihan index, partial restore, cross-cluster restore, dan perencanaan disaster recovery. Sampai jumpa!