Elasticsearch ve MongoDB'nin Rust ile RocksDB Kullanılarak Nasıl Değiştirildi

• Radar, günde 10 milyardan fazla API isteği işleyen bir coğrafi veri altyapısı sunuyor ve performans ile ölçeklenebilirlik sorunlarını çözmek için mevcut Elasticsearch ve MongoDB'yi kendi geliştirdiği HorizonDB ile değiştirdi
• HorizonDB, Rust ile geliştirilmiş olup RocksDB, S2, Tantivy, FST, LightGBM, FastText gibi çeşitli açık kaynak araçlarını birleştiren yüksek performanslı bir coğrafi veritabanıdır
• Eski yapıda Elasticsearch ve MongoDB'nin ölçekleme maliyeti ve karmaşıklığı yüksek olduğu için operasyon zorlukları vardı
• HorizonDB, tek iş parçacıklı çoklu süreç (single multithread process) olarak çalışarak maliyet azaltımı, performans artışı ve yüksek güvenilirlik sağlıyor
• Genel olarak geliştirme verimliliği ve operasyonel verimlilik ciddi şekilde arttı; yeni veri veya özelliklerin hızlı uygulanabilirliği mümkün hale geldi
• Veriler Apache Spark ile ön işleme alındıktan sonra AWS S3'e sürüm bazlı kaydediliyor ve geliştiriciler bunu yerel ortamlarında da kolayca çalıştırıp test edebiliyor
• Böylece Mongo ve Elasticsearch kümeleri kapatılarak maliyetler önemli ölçüde düşürüldü ve özellik geliştirme hızı ile veri işleme verimliliği iyileştirildi

---

Giriş ve Arka Plan

• Radar, dünya genelinde yüz milyonlarca cihazdan günde 1 milyardan fazla API çağrısını işleyen bir jeolokasyon altyapı platformudur
  • Başlıca API'ler: Geocoding, Search, Routing, Geolocation compliance vb.
• Veri ölçeği ve ürün büyüdükçe yüksek performans, ölçeklenebilirlik ve maliyet problemleri acil hale geldi
• Bunun için Rust ile yazılmış HorizonDB devreye alındı ve farklı konum servisleri tek bir yüksek performanslı binary'de sunuldu
  • Çekirdek başına 1.000 QPS işleniyor
  • İleri geokodlama ortanca gecikmesi 50 ms, ters geokodlama <1 ms
  • Genel donanımda doğrusal ölçeklenebilirlik

Mevcut Sistemlerin Sınırları

• Önceki mimari: ileriye dönük geokodlama Elasticsearch ile, geriye dönük geokodlama MongoDB ile işlendi
• Sorunlar:
  • Elasticsearch, sorguları tüm shard'lara dağıtıyor ve periyodik toplu güncelleme gerektiriyordu
  • MongoDB, büyük hacimli toplu girdi almakta zorlanıyor; fazla kaynak tahsisi ve güvenilir rollback (geri alma) eksikliği yaşanıyordu

HorizonDB Mimari Hedefler

• Verimlilik - Genel donanımda çalışabilme, öngörülebilir otomatik ölçekleme, tüm coğrafi varlıklar için tek bir veri kaynağı rolü üstlenme
• İşletilebilirlik - Veri varlıkları gün içinde birden fazla kez derlenip işlenebiliyor, değişiklik ve geri dönüş (rollback) kolay, operasyonun sadeleşmesi
• Geliştirme deneyimi - Yerel ortamda çalıştırılabilir, değişiklik ve testleri kolaylaştırma

Kullanılan Teknoloji Yığını

RocksDB, S2, Tantivy, FST'ler, LightGBM, FastText gibi bir dizi açık kaynağı bir arada kullanarak, veriler Apache Spark ile ön işleme alınıyor ve Rust'ta S3 üzerinde sürüm kontrollü dosyalar olarak saklanıyor

• Rust

  • Mozilla tarafından geliştirilmiş bir sistem programlama dili
  • Derleme ve bellek güvenliği sağlar, çöp toplama olmadan öngörülebilir büyük indeks belleği yönetimi mümkün
  • Null işleme, pattern matching gibi yüksek seviyeli soyutlamalar ile karmaşık arama sıralama mantığını kolayca ifade edebilme
  • Tek çok iş parçacıklı süreç olarak SSD'de yüzlerce GB veri işlemeye optimize edilmiş

• RocksDB

  • Yüksek performanslı LSM ağaç tabanlı in-proses depolama
  • Mikrosaniye düzeyinde yanıt, büyük veri kümesi boyutlarında bile stabil hız

• S2

  • Google'ın uzamsal indeksleme kütüphanesi olarak Dünya'yı dörtleme yaparak nokta-poligon sorgularını hızlandırır
  • Radar, C++ S2 kütüphanesi için Rust bağlayıcılarını kendisi geliştirdi; yakında açık kaynak olarak yayımlanması planlanıyor

• FST'ler (Finite State Transducers)

  • Verimli dize sıkıştırma ve önek arama veri yapısı
  • Sorguların %80'inin düzenli “happy-path” olduğunu yansıtarak, yalnızca birkaç MB bellekle yüzlerce milyon yolu önbelleğe alma imkânı sunuyor

• Tantivy

  • Lucene'e benzer in-proses ters indeksleme kütüphanesi
  • Elasticsearch gibi harici bir servis yerine bunu seçme nedenleri:
    • Arama kalitesi - dinamik anahtar genişletme gibi gelişmiş arama işlemlerine UML iletişim gecikmesi olmadan yanıt verebilme
    • Operasyonel basitleştirme - tek süreç içinde işleme; büyük indeksler de bellek eşlemleme ile kolayca ölçeklendirilebilir

• FastText

  • Kendi korpusu ve günlükleriyle eğitilmiş FastText modeli kullanılarak kelime vektör temsilleri üretip ML uygulamalarında kullanılıyor
  • Yazım hatalarına ve bilinmeyen sözcüklere karşı dayanıklı; komşu vektörlerin anlamsal benzerliğinden yararlanarak arama anlamsal anlayışı sağlıyor

• LightGBM

  • Sorgu niyeti sınıflandırma, sorgu içi nitelik etiketleme gibi birden çok LightGBM modeli kullanılıyor
  • Örnek: “New York” gibi bölge odaklı bir sorgu için adres araması atlanıyor, “841 Broadway” durumunda POI/bölge keşfi atlanıyor

• Apache Spark

  • Yüz milyonlarca veri noktasını 1 saat içinde hızlı şekilde işleyerek join/toplama performansını artırmak için iş akışı sürekli iyileştiriliyor
  • Nihai veriler S3'te saklanıyor, Amazon Athena veya DuckDB ile SQL tabanlı sonuç keşfi yapılabiliyor

HorizonDB Uygulama Sonuçları

• Hizmet önemli ölçüde hızlandı, operasyonlar basitleşti, güvenilirlik arttı
• Geliştirme ekibi, yeni özellik ve veri kaynaklarını bir gün içinde uygulayıp değerlendirebiliyor
• Mongo, Elasticsearch gibi büyük ölçekli kümeler ve çok sayıda mikroservis kapatılarak aylık on binlerce dolar tasarruf sağlandı

• Radar, gelecekteki büyük ölçekli büyümeye yanıt vermeye hazır. Belirli özelliklerin tasarım süreci ileride bir blogda paylaşılıyor