Belajar Elasticsearch - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita tahu mengapa Elasticsearch lahir: mengubah Lucene — library pencarian — menjadi engine terdistribusi yang mudah diakses. Sekarang kita masuk ke bagian paling penting dalam memahami Elasticsearch: bagaimana ia bekerja di dalam. Tanpa pemahaman ini, kalian akan mengetik perintah seperti robot yang menghafal — bisa jalan, tapi tidak mengerti mengapa.

Episode 2 membahas fondasi arsitektur: hierarki document-index, mekanisme inverted index, sharding dan replication, jenis-jenis node, proses indexing dan pencarian dari awal sampai akhir, serta trade-off konsistensi. Ini episode teori paling padat di series ini — kalian akan kembali merujuk ke sini terus-menerus.

#Document, Index, dan Hierarchy

#Dokumen sebagai Unit Data

Unit data dasar Elasticsearch adalah document: objek JSON yang menyimpan field dengan nilai. Satu dokumen merepresentasikan satu entitas — satu produk, satu log, satu artikel. Tidak seperti tabel SQL, dokumen tidak wajib punya field yang sama persis; satu dokumen boleh punya field yang tidak dimiliki dokumen lain.

{
  "name": "Kaos Polos Premium",
  "price": 99000,
  "category": "fashion",
  "in_stock": true,
  "tags": ["casual", "basic"]
}

#Hierarki: Index dan Document

Elasticsearch punya tiga level hierarki: cluster (kumpulan node), index (kumpulan dokumen dengan mapping sama, analogi tabel), dan document (analogi baris). Konsep type — level antara index dan document — sudah dihapus sejak Elasticsearch 8.0; sekarang satu index hanya berisi satu jenis dokumen.

Satu index memiliki settings (berapa shard, berapa replica, konfigurasi refresh) dan mapping (definisi tipe data tiap field). Keduanya dibahas dalam di episode 4 dan 5.

#Inverted Index

Ini adalah jantung Elasticsearch. Inverted index adalah struktur data yang memetakan setiap istilah (term) ke daftar dokumen yang mengandungnya. Analogi paling mudah: indeks di belakang buku pelajaran. Kalian tidak membaca seluruh buku untuk mencari kata "sharding" — kalian buka indeks, cari "sharding", dan langsung diarahkan ke halaman tertentu.

{
  "elasticsearch": ["doc-1", "doc-2"],
  "search": ["doc-1"],
  "analytics": ["doc-2"]
}

Saat kalian mencari kata "search", Elasticsearch tinggal lookup istilah itu di inverted index dan langsung tahu dokumen doc-1 cocok — tanpa memindai seluruh dokumen. Kecepatan pencarian karena itu hampir konstan, tidak bergantung pada jumlah dokumen. Inilah yang membuat LIKE di SQL kalah telak: LIKE harus membaca setiap baris, Elasticsearch langsung menunjuk dokumen yang tepat.

#Sharding dan Replication

#Sharding: Memecah Data

Satu index tidak harus berada di satu mesin. Elasticsearch membagi index menjadi shards — potongan data independen yang tersebar di beberapa node. Jumlah primary shards ditentukan saat index dibuat dan tidak bisa diubah setelahnya (kecuali lewat reindex, episode 13). Inilah mekanisme scale out: 100 juta dokumen bisa disebar ke 10 shards di 5 node, dan setiap node hanya menangani sebagian pekerjaan.

#Replication: Menyalin untuk Ketahanan dan Performa

Setiap primary shard memiliki replica shards — salinan persis yang berada di node berbeda. Replica punya dua fungsi: ketahanan (jika node mati, replica menggantikan primary) dan performa baca (pencarian bisa dibagi ke primary dan replica). Semua operasi tulis menuju primary, lalu disebar ke replica secara asinkron.

curl -s localhost:9200/_cat/shards?v

Perhatikan kolom pri dan rep: jumlah primary dan replica. Kalian akan sering melihat angka rep 0 di setup awal — untuk production, minimum 1 replica.

#Arsitektur Node dan Cluster

Sebuah node adalah satu instance Elasticsearch; kumpulan node membentuk cluster. Satu node bisa memainkan beberapa peran sekaligus, ditentukan oleh node.roles di elasticsearch.yml:

Di cluster kecil, satu node menjalankan semua peran. Di cluster production besar, peran dipisah untuk isolasi beban — kita bahas di episode 14 dan 18. Master node mencatat cluster state: mapping, settings, lokasi setiap shard, dan index yang ada.

#Proses di Balik Layar

#Alur Indexing

Saat dokumen dikirim untuk diindeks: node penerima (coordinating) menghitung routing untuk menentukan primary shard mana yang menangani dokumen, mengirim dokumen ke node pemilik primary shard, menulis ke translog (log tulis untuk recovery) dan in-memory buffer, lalu secara berkala membentuk segment baru — file immutable di Lucene yang menyimpan inverted index. Data baru ini baru terlihat oleh pencarian setelah refresh (default 1 detik).

#Alur Pencarian

Saat query masuk: coordinating node mengirim query ke setiap shard dari index yang dicari, setiap shard mencari secara lokal, mengembalikan hasil plus skor relevansi, dan coordinating node menggabungkan (merge) hasil dengan mengurutkan berdasarkan skor. Ini sebabnya jumlah shard memengaruhi performa pencarian — makin banyak shard, makin banyak node yang harus "bertanya".

#Relevansi dan Scoring

Skor relevansi dihitung dengan model BM25: semakin sering kata muncul di dokumen (term frequency) dan semakin langka kata itu di seluruh index (inverse document frequency), semakin tinggi skornya. Panjang dokumen juga diperhitungkan — dokumen pendek dengan kata itu dianggap lebih relevan.

#Segment dan Merge Process

Lucene menulis data sebagai segments yang immutable — tidak bisa diubah, hanya bisa dibuat baru. Seiring waktu, banyak segment kecil menumpuk, dan Lucene menjalankan merge: menggabungkan segment kecil menjadi satu segment besar. Saat merge, dokumen yang dihapus benar-benar dibuang. Ini background process yang terus berjalan, dan pemahaman segment inilah yang jadi dasar pengaturan refresh_interval dan translog di episode 19.

#CAP Theorem dan Eventual Consistency

Elasticsearch menekankan availability dan partition tolerance, dan untuk tulis, konsistensi-nya eventual: dokumen yang baru diindeks bisa tidak langsung terlihat di semua replica (dibutuhkan waktu replikasi). Baca dengan _primary dan _replica preference membolehkan kalian memilih membaca dari primary atau membiarkan replica, dengan trade-off konsistensi vs performa.

Ada satu pengecualian penting: pencarian real-time untuk dokumen yang baru ditulis — Elasticsearch menjamin dokumen terlihat satu detik setelah ditulis (karena refresh interval). "Real-time" di Elasticsearch artinya near-real-time, bukan millisecond-consistent seperti database transaksional.

#Penutup

Di episode 2 kalian memahami arsitektur inti Elasticsearch: document sebagai unit data JSON, index sebagai kumpulan dokumen bermapping sama, inverted index sebagai rahasia kecepatan pencarian, shards dan replicas sebagai mekanisme distribusi dan ketahanan, peran-peran node dalam cluster, serta alur indexing dan pencarian yang melibatkan translog, segment, refresh, dan merge. Kalian juga memahami posisi Elasticsearch dalam CAP theorem: available dan partition tolerant, dengan eventual consistency.

Inti yang harus dibawa pulang:

• Hierarki data: cluster → index → document; konsep type sudah dihapus di 8.x.
• Inverted index membuat pencarian jadi lookup, bukan scan — kecepatan hampir konstan di data besar.
• Primary shards tidak bisa diubah jumlahnya setelah index dibuat.
• Replicas menyediakan ketahanan sekaligus performa baca.
• Pencarian dijalankan ke semua shard, lalu hasil digabung di coordinating node.
• Relevansi memakai BM25; data ditulis ke segments immutable yang di-merge berkala.

Sekarang teori sudah cukup untuk mulai praktik. Di episode 3 kita akan menginstall Elasticsearch dan menjalankan instance pertama: metode instalasi (APT, archive, Docker), menyalakan dan mematikan service, memeriksa cluster health, memahami struktur respons JSON, dan mengenal Dev Tools di Kibana. Sampai jumpa!