Cara Mengganti Elasticsearch dan MongoDB dengan Rust dan RocksDB

 (radar.com)
4 poin oleh GN⁺ 2025-08-10 | 1 komentar | Bagikan ke WhatsApp
  • Radar menyediakan infrastruktur geoinformasi yang menangani lebih dari 1 miliar permintaan API per hari, dan beralih dari Elasticsearch dan MongoDB yang sudah ada ke HorizonDB buatan internal untuk mengatasi isu kinerja dan skalabilitas
  • HorizonDB dikembangkan menggunakan Rust dan merupakan database geoinformasi berkinerja tinggi yang menggabungkan berbagai alat sumber terbuka seperti RocksDB, S2, Tantivy, FST, LightGBM, FastText, dan lain-lain
  • Pada arsitektur lama, biaya dan kompleksitas penskalaan Elasticsearch serta MongoDB menjadi besar sehingga menimbulkan kesulitan dalam pengoperasian
  • HorizonDB beroperasi dengan model proses tunggal multithread, sehingga mencapai penghematan biaya, peningkatan kinerja, dan keandalan tinggi
  • Secara keseluruhan, produktivitas pengembangan dan efisiensi operasi meningkat secara signifikan, sehingga memungkinkan penerapan cepat data dan fitur baru
  • Data setelah dipraproses dengan Apache Spark disimpan per versi di AWS S3, dan dapat dengan mudah dijalankan serta diuji oleh pengembang di lingkungan lokal
  • Dengan demikian, klaster Mongo dan Elasticsearch ditutup, menurunkan biaya secara signifikan, serta memperbaiki kecepatan pengembangan fitur dan efisiensi pemrosesan data

Pengenalan dan Latar Belakang

  • Radar adalah platform infrastruktur geolokasi yang menangani lebih dari 1 miliar panggilan API per hari dari ratusan juta perangkat di seluruh dunia
    • API utama antara lain Geocoding, Search, Routing, Geolocation compliance
  • Dengan meningkatnya skala data dan produk, penyelesaian isu kinerja, skalabilitas, dan biaya menjadi sangat mendesak
  • Untuk itu, HorizonDB yang ditulis dengan Rust diadopsi untuk menyediakan berbagai fungsi layanan lokasi dalam satu binary berkinerja tinggi
    • Memproses 1.000 QPS per inti
    • Latensi median geocoding maju 50ms, geocoding balik <1ms
    • Dapat diskalakan secara linear di perangkat keras umum

Batasan Sistem Lama

  • Struktur sebelumnya: geocoding maju ditangani oleh Elasticsearch, dan geocoding balik oleh MongoDB
  • Permasalahan:
    • Elasticsearch membagi query ke seluruh shard, memerlukan pembaruan batch secara berkala
    • MongoDB sulit menerima input batch skala besar, dan kekurangan alokasi sumber daya berlebihan serta fitur rollback yang andal

Tujuan Arsitektur HorizonDB

  • Efisiensi - Beroperasi pada perangkat keras umum, autoscaling yang dapat diprediksi, bertindak sebagai satu sumber data untuk semua entitas geospasial
  • Operabilitas - Membangun dan memproses aset data beberapa kali sehari, perubahan dan rollback mudah, penyederhanaan operasi
  • Pengalaman Pengembang - Dapat dijalankan di lingkungan lokal, mudah melakukan perubahan dan pengujian

Tumpukan Teknologi yang Digunakan

RocksDB, S2, Tantivy, FST, LightGBM, FastText, dan beberapa open-source lain digunakan, dengan data yang dipraproses oleh Apache Spark lalu disimpan sebagai file versi-ke-versi di S3 melalui Rust

  • Rust

    • Bahasa pemrograman sistem yang dikembangkan oleh Mozilla
    • Menjamin keamanan kompilasi dan memori, memungkinkan pengelolaan memori indeks berskala besar yang prediktabel tanpa garbage collection
    • Mendukung abstraksi tingkat tinggi seperti penanganan null dan pattern matching, sehingga ekspresi logika peringkat pencarian yang kompleks menjadi mudah
    • Dioptimalkan untuk memproses ratusan GB data di SSD dengan single-process multithreaded

  • RocksDB

    • Penyimpanan in-process berbasis pohon LSM berkinerja tinggi
    • Respons dalam skala mikrodetik, stabil kecepatan pada data berskala besar

  • S2

    • Pustaka pengindeksan spasial dari Google yang membagi bumi menjadi kuadran untuk mempercepat query titik-ke-poligon
    • Radar mengembangkan binding Rust untuk pustaka C++ S2 sendiri dan akan segera merilisnya sebagai sumber terbuka

  • FSTs (Finite State Transducers)

    • Struktur data untuk kompresi string yang efisien dan pencarian awalan
    • Mencerminkan bahwa 80% query adalah “happy path” yang teratur, memungkinkan caching ratusan juta jalur dengan memori hanya beberapa MB

  • Tantivy

    • Pustaka inverse index in-process yang mirip Lucene
    • Alasan mengadopsi dibandingkan layanan eksternal seperti Elasticsearch:
      • Kualitas pencarian - Menangani pemrosesan pencarian lanjutan seperti perluasan kata kunci dinamis tanpa latensi komunikasi UML
      • Penyederhanaan operasi - Pemrosesan dilakukan dalam satu proses, indeks skala besar pun dapat diskalakan dengan mudah melalui memory mapping

  • FastText

    • Menggunakan model FastText yang dilatih dengan korpus dan log internal untuk menghasilkan representasi vektor kata, lalu dimanfaatkan pada aplikasi ML
    • Tangguh terhadap salah ketik dan kata tidak terdaftar, memanfaatkan kemiripan semantik vektor tetangga untuk memungkinkan pemahaman makna pencarian

  • LightGBM

    • Memanfaatkan banyak model LightGBM untuk klasifikasi intent query, atribut tagging di dalam query, dan lain-lain
    • Contoh: query wilayah seperti “New York” melewati pencarian alamat, dan untuk kasus seperti “841 Broadway” maka melewati pencarian POI/area

  • Apache Spark

    • Memproses ratusan juta titik data dalam waktu kurang dari 1 jam, dengan perbaikan berkelanjutan untuk meningkatkan kinerja join/agregasi
    • Data akhir disimpan di S3 sehingga eksplorasi hasil berbasis SQL dapat dilakukan dengan Amazon Athena atau DuckDB

Hasil Penerapan HorizonDB

  • Layanan menjadi jauh lebih cepat, operasi disederhanakan, dan keandalan ditingkatkan
  • Tim pengembang dapat menerapkan dan mengevaluasi fitur serta sumber data baru dalam satu hari
  • Penghematan puluhan ribu dolar per bulan lewat penghentian klaster besar seperti Mongo, Elasticsearch, dan beberapa microservice lainnya
  • Radar telah menyelesaikan persiapan untuk menghadapi skala yang jauh lebih besar. Proses desain fitur tertentu akan diperkenalkan di blog di kemudian hari

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-10
Komentar Hacker News

  • Aku merasa ini kurang beruntung karena detailnya minim dan sepertinya tidak ada rencana untuk menjadikannya open source. Kalau kamu mengklik artikel ini saat mencari alternatif ES (ElasticSearch), aku ingin merekomendasikan typesense.org dan duckdb.org (terutama dengan plugin spatial), karena kedua layanan ini unggul dalam performa data spasial, dan DuckDB juga terlihat sangat cocok untuk dipakai di layanan produksi pada data yang tidak terlalu sering berubah. Dalam konfigurasi cluster/sharding pun, semuanya tetap sepenuhnya open source. Ini adalah rekomendasi berbasis pengalaman pakai murni, tanpa hubungan apa pun.

    • Kedua proyek ini benar-benar hebat. Tim kami saat ini juga aktif menggunakan DuckDB untuk pemeriksaan data lake dan pemrosesan data sederhana. Kami berencana menambahkan artikel blog yang menjelaskan bagian-bagian sistem secara lebih detail. Kami memutuskan menyebarkan konten karena khawatir terlalu banyak materi dalam satu postingan akan sulit dibaca.

    • Aku sangat berterima kasih karena ada proyek open source seperti ini, meski mengintegrasikannya ke proyekku terasa tidak mudah. Dulu, saat mencoba membangun dengan duckdb.org, spatial, dan ekstensi SQLite yang di-link secara statis, akhirnya kusadari itu melelahkan karena build gagal akibat simbol SQLite versi berbeda.

    • Apakah DuckDB tidak punya sharding atau clustering sama sekali? Tidak ada server terpisah (kecuali HTTP Server Extension).

    • Typesense performanya benar-benar bagus dan pengalaman pengembangannya juga sangat memuaskan.

    • Aku juga belum yakin apa yang benar-benar mesti dibuka sebagai open source—kode Rust-nya atau apa. Meski dideklarasikan sebagai DB, kesannya seperti menjelaskan seluruh stack.

  • Aku merasa lucu ketika halaman lowongan kerja menempatkan budaya kerja kantor sebagai benefit pertama; aku benar-benar penasaran bagaimana commute bisa jadi sebuah benefit.

    • Commute vs remote bukan hanya soal waktu tempuh. Ada banyak faktor lain: lingkungan kerja, work-life balance, dan lain-lain. Pengalamanku, saat commute di bawah 30 menit dan bisa ditempuh dengan jalan kaki atau sepeda, sangat menyenangkan: bisa olahraga, merapikan pikiran, dan membantu transisi dari rumah ke kerja. Saat sempat WFH penuh di 2020, semakin sulit tetap bisa memisahkan kerja dan istirahat di ruang yang sama, jadi tiap hari setelah pulang aku jalan satu jam dan itu sangat membantu pemulihan mental. Tapi, ketika pulang-pergi lebih dari satu jam memakai transportasi umum atau jalan tol, rasanya sangat berat.

    • Menurutku budaya kantor baru benar-benar jadi keunggulan kalau ada kesempatan belajar dari orang pintar, membangun relasi teman, makanan/minuman gratis, mesin DDR, dan sebagainya. Di pengalaman kantor terakhirqku, tidak ada sama sekali dan suasananya seperti suasana kerja dari rumah yang dibesarkan skalanya—jadi murung.

    • Beberapa orang bisa jadi suka datang ke kantor; tiap orang beda.

    • Aku lebih suka commute dibanding remote; jadi ada orang yang jelas berpikir bahwa "commute itu benefit".

  • Aku penasaran apakah sistem ini bisa berguna untuk Photon, mesin Elasticsearch/OpenSearch open source untuk data OSM (OpenStreetMap). Pengalaman pencarian di sebagian besar aplikasi OSM umumnya tidak bagus dan lemah terhadap typo, sementara Photon membawa inovasi kecil di area ini. Tautan GitHub Photon

    • Dalam kasus ini, aku rasa sistem yang dibangun dengan LMDB lebih cocok daripada RocksDB. Sebagai referensi, OSM Express sudah memakai LMDB. Tautan wiki OSM Express

  • Pendapatnya metasekalian, tetapi aku senang melihat kembali ramai-nya desain penyimpanan data internal atau query engine dan tulisan blog di area ini. Di era 2010-an pernah ada hype semacam ini, dan akhir-akhir ini kecenderungannya ke AI.

    • Menurutku hype itu bukan karena AI, melainkan karena akhirnya terbukti sebagian besar solusi di situ tidak berguna. Kita bisa menyetel atau memperluas sistem yang ada sampai performanya memadai, sehingga stack internal yang terlalu spesifik akhirnya tidak dibutuhkan. Sistem penyimpanan/query internal yang tidak direncanakan untuk dijual sebagai produk pada akhirnya jadi sindrom NIH (Not Invented Here) di perusahaan yang punya banyak sumber daya.

    • NoSQL/database alternatif sempat menyebar seperti tren, lalu meredup saat orang menyadari bahwa untuk kebanyakan perusahaan, Postgres saja sudah cukup.

    • Aku belum tahu apakah masih ada lagi hal untuk diinnovasi. Aku memilih produk yang bisa dipercaya dan terverifikasi daripada penyimpanan eksperimental.

  • Menurutku aneh artikel ini menaruh kata "Rust" di judulnya sendiri. Kalau jadi pembaca, orang bisa bingung Rust menggantikan apa—ElasticSearch atau MongoDB.

  • Artikel ini terlalu sedikit detailnya; misalnya soal metode sharding data, delay antar proses indexing dan layanan, penanganan node yang rusak, serta latency di sistem terdistribusi—banyak poin penting yang hilang.

  • Dari sisi search, menarik mengamati akhir-akhir ini berapa banyak perusahaan yang menargetkan "pengganti ElasticSearch".

    • Aku penulisnya! Dari sisi operasi, aku terdorong mengganti masalah "sistem terdistribusi" menjadi "sistem monolitik". Aku memilih sistem penyimpanan embedded seperti RocksDB dan Tantivy karena sekarang aku merasa hardware pun sudah cukup. Dengan memory-mapping, kami bahkan bisa memenuhi skenario cakupan global; di cloud juga fleksibel menambah RAM. Untuk backfill dan update data, aku menanganinya simpel: di node baru, reindex penuh dengan binary yang sama lalu kirim ke S3, tanpa perlu memikirkan status ES/Mongo secara terpisah.

    • Aku sering merasa upaya dan waktu untuk mengoperasikan serta mengelola cluster ElasticSearch jauh lebih besar dibandingkan database produksi riil. Karena itu, di banyak kasus aku makin terdorong memakai alternatif yang lebih sederhana dengan menyediakan fitur ES yang sedikit saja, agar lebih minim rusak.

  • Menarik melihat banyak perusahaan yang menyusun solusi yang benar-benar pas untuk mereka; apalagi memulai memakai open source komersial daripada membuat solusi sendiri dari awal aku lihat sangat positif. Kebetulan, dari Tantivy aku tertarik dengan Quickwit; kesannya mirip ES berbasis Lucene. Tautan GitHub Quickwit

    • tantivy :)

  • Rocks adalah fork dari Level, dan Level sudah dikenal karena bug seperti kerusakan data. Kedua sistem ini memang banyak dipakai di produksi, tapi saat aku memakai Level, tim operasi saya harus ngurus error dengan sangat berat untuk menjaga layanan tetap jalan. Blog-post perusahaan seperti ini hampir tidak pernah menyebut jujur kekurangan atau isu serius dari stack teknologi baru; tech talk perusahaan "big name" pun pada akhirnya promosi cerita sendiri.

    • RocksDB sudah lama pisah dari LevelDB dan sudah mengalami perbaikan besar di industri dan akademisi, jadi sekarang bukan lagi database mainan seperti LevelDB. Mungkin ada kekurangan yang belum kami temukan, tapi aku melihat kemungkinan ada masalah besar di RocksDB sangat kecil.

    • Pengalamanku juga berbeda. Selama 4 tahun terakhir, aku menjalankan RocksDB di ribuan server (beberapa terabyte data per server) tanpa pernah melihat error dari RocksDB itu sendiri.

  • Aku mengklik karena kata kunci Elasticsearch, tapi heran karena dulu tidak tahu radar.com. Aku tertarik karena melihat fitur autocomplete dengan harga yang pas untuk kebutuhanku.