Cara Mengganti Elasticsearch dan MongoDB dengan Rust dan RocksDB

• 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