Belajar Elasticsearch - Sejarah, Latar Belakang & Mengapa Membutuhkan Elasticsearch
Dari grep dan SQL LIKE menuju full-text search engine: sejarah Apache Lucene, perjalanan Elasticsearch dari 2010 hingga Elastic Stack, masalah yang diselesaikannya, serta perbandingan dengan RDBMS, Apache Solr, dan Algolia.
#Pendahuluan
Di episode 0 kalian sudah memastikan environment siap: JDK, Elasticsearch 8.x, Kibana, dan mentalitas debugging yang benar. Sekarang saatnya menjawab pertanyaan paling mendasar: kenapa sebenarnya ada Elasticsearch? Mengapa database relasional yang sudah puluhan tahun mapan tidak cukup untuk masalah pencarian?
Episode 1 ini adalah episode "bercerita". Kita tidak akan banyak mengetik, tapi kalian akan memahami konteks yang membuat setiap keputusan desain Elasticsearch masuk akal — dan konteks itu akan terus kalian bawa sampai episode 30. Kita bahas evolusi teknologi search, masalah yang dipecahkan Elasticsearch, perjalanannya dari 2010 hingga sekarang, dan perbandingannya dengan solusi lain.
#Evolusi Teknologi Search
#Era grep dan SQL LIKE
Sebelum ada search engine modern, orang mencari teks dengan dua cara. Yang pertama: grep di command line — membaca file satu per satu dan mencocokkan pola. Yang kedua: query SQL dengan LIKE '%kata%' di database. Keduanya bekerja, tapi keduanya linear — harus memindai seluruh data setiap kali mencari.
SELECT * FROM posts
WHERE title LIKE '%elasticsearch%'Permasalahan LIKE ada tiga. Pertama, lambat di data besar karena full table scan. Kedua, tidak relevan — tidak ada cara memberi peringkat hasil berdasarkan seberapa mirip. Ketiga, tidak fleksibel — tidak bisa mencari sinonim, kata dasar, atau menangani typo. Inilah celah yang coba diisi oleh full-text search engine.
#Apache Lucene: Fondasi Segalanya
Apache Lucene adalah library pencarian teks berbahasa Java yang dirilis pertama kali tahun 2000 oleh Doug Cutting — orang yang sama yang kemudian membangun Hadoop. Lucene memperkenalkan inverted index: struktur data yang memetakan setiap istilah ke daftar dokumen yang mengandungnya. Ini mengubah pencarian dari pemindaian linear menjadi lookup langsung — sangat cepat bahkan di jutaan dokumen.
Masalahnya: Lucene hanyalah library, bukan server. Untuk memakainya, developer harus menulis kode Java, mengelola file index secara manual, dan tidak ada cara mudah mengaksesnya lewat jaringan. Butuh bertahun-tahun, ribuan baris kode, dan hanya bisa dipakai dari dalam satu aplikasi Java.
#Timeline Perkembangan Elasticsearch
| Tahun | Peristiwa |
|---|---|
| 2000 | Apache Lucene pertama kali dirilis sebagai library pencarian |
| 2004 | Shay Banon mulai membangun Compass, solusi pencarian di atas Lucene |
| 2010 | Elasticsearch 0.4 dirilis sebagai engine terdistribusi berbasis Lucene |
| 2013 | Perusahaan Elastic didirikan oleh Shay Banon, Steven Schuurman, Uri Boness |
| 2015 | ELK Stack (Elasticsearch, Logstash, Kibana) jadi produk unggulan |
| 2016 | Beats diperkenalkan; ELK resmi berganti nama menjadi Elastic Stack |
| 2018 | Elasticsearch menjadi open source project paling populer di GitHub untuk kategori server |
| 2020 | Elasticsearch 7.x menghentikan konsep mapping type |
| 2022 | Elasticsearch 8.0: keamanan default aktif, TSDS, dan sederet fitur baru |
| 2024 | Elasticsearch 8.x terus menambahkan vector search, ELSER, dan integrasi LLM |
Perjalanan ini penting karena menjelaskan dua karakter Elasticsearch. Pertama, ia lahir dari rasa frustrasi — Shay Banon ingin membangun aplikasi pencarian resep, tapi Compass terasa terlalu rumit, sehingga ia menulis engine yang lebih sederhana dan mudah dipakai. Kedua, ia tumbuh melampaui search — dari sekadar pencarian, kini mencakup observability, security analytics, dan machine learning.
#Masalah yang Diselesaikan Elasticsearch
#Limitasi Database Relasional untuk Full-Text Search
Database relasional unggul di transactional consistency, tapi buruk untuk pencarian teks bebas. Query LIKE tidak bisa memberi peringkat relevansi, tidak mengerti stem kata, dan lambat. Elasticsearch mengisi peran ini sebagai specialized search layer di samping database utama — arsitektur yang lazim disebut dual-write atau outbox pattern.
Bayangkan katalog toko dengan jutaan produk. LIKE '%blend%' di SQL tidak akan menemukan "blended", "blending", atau "blends" — sementara search engine dengan stemming (episode 7) dan scoring relevansi (episode 6) bisa mencocokkan dan memberi peringkat hasil berdasarkan kemiripan. Inilah yang membuat Elasticsearch lebih dari sekadar "database yang lebih cepat mencari".
#Kebutuhan Real-Time Search dan Analytics
Data masuk terus-menerus — log server, klik pengguna, event IoT — dan pertanyaan yang diajukan bukan hanya "apa yang cocok", tapi "berapa banyak", "berdasarkan apa", "kapan". Elasticsearch menggabungkan pencarian dan aggregation dalam satu engine, sehingga dashboard real-time dan pencarian bisa berbagi data yang sama.
Kecepatan juga bagian dari janji real-time: dokumen yang di-index bisa dicari hampir seketika, cukup cepat untuk memberi feedback instan di UI pencarian. Mekanisme yang membuatnya cepat — segmen Lucene dan refresh interval — akan kalian bedah lebih dalam di episode 7 dan 19.
#Skalabilitas Horizontal untuk Big Data
Database relasional umumnya di-scale dengan memperbesar satu mesin (scale up), dan itu ada batasnya. Elasticsearch dirancang terdistribusi sejak awal: data dipecah menjadi shards yang tersebar di banyak node. Menambah kapasitas cukup dengan menambahkan mesin baru — tanpa mengubah aplikasi. Ini yang disebut scale out.
#Tantangan Arsitektur Distributed
Tentu saja ada harga yang harus dibayar. Data tersebar berarti ada masalah konsistensi, partition, dan failover. Elasticsearch menjawabnya dengan replication (salinan data per shard), discovery antar-node, dan pemilihan master otomatis — konsep yang akan kalian kuasai di episode 2, 14, dan 29.
#Perbandingan dengan Solusi Lain
#Elasticsearch vs RDBMS (PostgreSQL, MySQL)
Database relasional tetap raja untuk transaksi dan data terstruktur yang butuh integritas ACID. Elasticsearch unggul di pencarian teks, relevansi, dan aggregation. Bukan "salah satu", tapi "saling melengkapi" — mayoritas arsitektur production memakai keduanya secara berdampingan.
#Elasticsearch vs Apache Solr
Solr juga berbasis Lucene dan lebih dulu populer (2004). Elasticsearch menang karena lebih sederhana — konsep cluster dan sharding yang mudah diakses lewat REST API tanpa konfigurasi ZooKeeper terpisah. Dokumentasi yang bagus dan komunitas yang besar membuat Elasticsearch jadi pilihan default baru.
#Elasticsearch vs Algolia
Algolia adalah managed SaaS search — dipakai jika tim tidak ingin mengelola infrastruktur. Elasticsearch memberi kendali penuh, harga lebih murah di skala besar, dan ekosistem lengkap, tapi menuntut kemampuan operasional. Pilih Algolia untuk kecepatan launch; pilih Elasticsearch untuk kontrol dan skala.
#Use Cases Utama
| Use Case | Contoh | Fitur Kunci |
|---|---|---|
| Application search | Pencarian produk e-commerce, search box aplikasi | Full-text search, relevansi, highlight |
| Logging & observability | Sentralisasi log semua server dengan ELK | Ingest pipeline, aggregation, data streams |
| Security analytics | Deteksi anomali di log keamanan | EQL, ML job, SIEM |
| Metrics & monitoring | Dashboard metrik real-time | TSDB, date_histogram aggregation |
| Semantic search | Chatbot dan RAG berbasis embedding | Vector search, ELSER |
| Geospatial | "Toko terdekat dari lokasi saya" | Geo-point query, geo aggregation |
Tip
Jika ada satu kalimat untuk diingat dari episode ini: Elasticsearch ada di mana search dan analytics dibutuhkan dalam skala besar — dan ia lahir karena Lucene, meski hebat, tidak bisa dijadikan server. Seluruh kehebatan Elasticsearch berikutnya adalah hasil dari membuat Lucene terdistribusi dan mudah diakses.
#Penutup
Di episode 1 kalian memahami evolusi search: dari grep dan LIKE yang linear, ke Apache Lucene yang memperkenalkan inverted index, hingga Elasticsearch yang membungkus Lucene menjadi engine terdistribusi yang mudah diakses lewat REST API. Kalian juga melihat timeline 2010 hingga sekarang, masalah yang dipecahkan — limitasi RDBMS, real-time analytics, dan scaling horizontal — serta posisi Elasticsearch dibanding Solr, Algolia, dan database relasional.
Inti yang harus dibawa pulang:
LIKEdi SQL itu linear dan tanpa relevansi; inverted index membuat pencarian jadi lookup cepat.- Lucene adalah library, Elasticsearch menjadikannya server terdistribusi.
- Elasticsearch bukan pengganti RDBMS, melainkan lapisan search dan analytics di sampingnya.
- Ia terdistribusi sejak lahir: data dipecah ke shards, diskalakan dengan menambah node.
- Use case utamanya: aplikasi, logging, security, metrics, dan semantic search.
Sekarang saatnya beranjak ke fondasi teknis. Di episode 2 kita akan membedah konsep dasar dan arsitektur utama: apa itu index, document, shard, dan replica, bagaimana inverted index bekerja di balik layar, peran tiap jenis node dalam cluster, serta bagaimana Elasticsearch menjalankan proses indexing dan pencarian dari awal sampai akhir. Ini adalah episode paling penting untuk dipahami sebelum kalian mengetik perintah pertama — sampai jumpa!