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

 (radar.com)
4 puan yazan GN⁺ 2025-08-10 | 1 yorum | WhatsApp'ta paylaş
  • 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

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-10
Hacker News yorumu

  • Detayların eksik olması ve açık kaynak planı da görünmemesi üzücü geldi; ES(ElasticSearch) için bir alternatif ararken bu yazıyı açtıysanız, typesense.org ve duckdb.org’u (özellikle spatial eklentisiyle birlikte) önermeye değer bulurum. Her iki hizmet de mekânsal veri performansında çok iyi ve DuckDB, değişimin az olduğu verilerde üretimde kullanıma bile oldukça uygun görünüyor. Cluster/şardlama yapılandırmasında da tamamen açık kaynak. Bu tamamen bağımsız bir gözlem, yalnızca kullanım deneyimime dayanan bir öneri.

    • Bu iki proje gerçekten çok iyi; ekibimiz de DuckDB’yi veri gölü incelemelerinde ve basit veri işleme akışlarında aktif olarak kullanıyor. İleride sistemin farklı parçalarını detaylı anlatan ek blog yazıları eklemeyi planlıyoruz; bir gönderide çok fazla şey olması okunabilirliği düşürdüğü için içeriği dağıtmayı tercih ettik.

    • Bu tür açık kaynak projelere her zaman minnettarım ama bunları kendi projeme entegre etmenin kolay olmayacağını düşünüyorum. Eskiden duckdb, spatial ve SQLite eklentilerini statik olarak linkleyip derlemeye çalışmıştım, farklı SQLite sembol sürümleri yüzünden derleme başarısız oluyor ve işin ne kadar zor olduğunu anlamıştım.

    • DuckDB’de shardlama ya da klasterleme hiç mi yok? Sunucusu da ayrı değil (HTTP Server Extension hariç).

    • Typesense’in performansı gerçekten çok iyi ve geliştirme deneyimi de gerçekten memnun edici.

    • Neyin gerçekten açık kaynak olduğu belli değil; bu bir Rust kodu mu bilmiyorum. DB olarak adlandırılıyor ama aslında tam bir yığın anlatıyor.

  • İş başvurusu sayfalarında ilk avantaj olarak “ofis çalışma kültürü”nü öne çıkarmak komik geliyor; işe gidip gelmenin nasıl bir avantaj olduğuna gerçekten merakla bakıyorum.

    • Gidiş-geliş ile evden çalışmayı karşılaştırınca tek belirleyici seyahat süresi değil; çalışma ortamı, iş-yaşam dengesi gibi başka birçok değişken var. Benim için, işe gidip gelmenin 30 dakikanın altında olduğu ve yürüme ya da bisikletle gidilebildiği durumlarda bu çok keyifliydi; biraz egzersiz yapılıyor, zihni toparlamak mümkün oluyor ve ev ile iş arasında geçiş yapılabiliyor. 2020’de tamamen uzaktan çalışırken aynı mekânda çalışıp dinlenmek giderek zorlaşmıştı, o yüzden her akşam bir saat kadar yürüyüş yaparak zihnimi toparladım. Ama toplu taşımayla ya da otoyolda bir saatten fazla yolculuk yaptığım dönemler gerçekten zordu.

    • Ofis kültürü gerçekten avantaj olacaksa, zeki insanlardan öğrenme, yeni arkadaş edinme, ücretsiz yiyecek/içecek ve DDR makineleri gibi şeyler olmalı diyorum. Son ofis deneyimimde bu avantajların hiçbiri yoktu; evden çalışmayı büyütülmüş bir versiyona benzeten kasvetli bir atmosfer vardı.

    • Bazı kişiler için ofiste çalışmak iyi gelebilir, bu tamamen kişisel.

    • Ben evden çalışmaktan çok işe gidip gelmeyi tercih ediyorum; yani “gidiş-gelişin bir avantaj olduğu”nı düşünenlerin olduğu açık.

  • Bu sistemin, OSM (OpenStreetMap) verileri için açık kaynaklı bir ElasticSearch/OpenSearch motoru olan Photon’a yardımcı olup olmayacağını merak ediyorum; çoğu OSM uygulamasındaki arama deneyimi iyi değil ve yazım hatalarına karşı da zayıf, Photon bu alana küçük de olsa bir yenilik getirmiş.

    • Bu durumda RocksDB yerine LMDB ile kurulmuş bir sistem daha uygun olabilir. Not: OSM Express zaten LMDB kullanıyor: OSM Express wiki

  • Biraz meta bir gözlem ama, kendi veri deposu veya sorgu motoru tasarımı blog yazılarının yeniden canlanması sevindirici. 2010’larda böyle bir trend vardı ve son zamanlarda odağın çoğunlukla yapay zekâya kaydığı görülüyordu.

    • Bu trendin yapay zekâdan değil de çoğunun işe yaramaz olduğu ortaya çıktığı için oluştuğunu düşünüyorum; mevcut sistemi ayarlayarak veya ölçeklendirerek gereken performansa ulaşılabildiğinde, aşırı özelleşmiş dahili stack’lere gerek kalmıyor. Ürün olarak satmayı planlamayan dahili depolama/sorgu sistemleri nihayetinde kaynakları bol şirketlerin NIH (Not Invented Here) sendromuna dönüşüyor.

    • NoSQL/alternatif veritabanları bir ara dalga gibi yayıldı ama sonra çoğu şirkete tek bir Postgres’in yeterli olduğunun anlaşılmasıyla sönümlendi.

    • Daha fazla yenilik kalıp kalmadığından emin değilim; deneysel veri depolarından çok güvenilir ve kanıtlanmış ürünleri tercih ederim.

  • Makale başlığında “Rust” dilinin doğrudan yer alması garip geldi; okuyucu için Rust’ın neyi değiştirdiğinin net olmaması olabilir — ElasticSearch mi, MongoDB mi?

  • Bu makale çok az teknik ayrıntı veriyor. Örneğin veri sharding yöntemi, indeksleme ile servisler arası gecikme farkları, arızalı düğüm işleme ve dağıtık sistemlerde gecikme gibi birçok kritik konu eksik.

  • Arama tarafında çalışan biri olarak son dönemde “ElasticSearch alternatifi” hedefleyen şirket sayısını merakla izliyorum.

    • Yazı sahibiyim! Operasyonel açıdan “dağıtık sistem” sorununu “monolitik sisteme” çevirmek için motive oldu. Son zamanlarda donanım kapasitesiyle de bunu rahatça halledebildiğimizi görünce RocksDB, Tantivy gibi gömülü depolama sistemlerini seçtim. Bellek eşleme (mmap) sayesinde dünya ölçekte bir kapsama da yetebildik, ayrıca bulutta RAM genişletmek serbestti. Veriyi geri doldurma ve güncelleme işi, ES/Mongo’nun anlık durumunu ayrı takip etmeden, aynı binary ile yeni bir node’da tam reindexleyip S3’e göndermekle sorunsuzca çözülüyor.

    • ElasticSearch cluster’ını çalıştırıp yönetmek için harcanan çaba ve zamanın, gerçek bir operasyonel veritabanına göre çok daha fazla olduğunu sıkça hissettim. Bu yüzden birçok durumda ES’in tüm özellikleri yerine daha az ama daha güvenilir, kırılmaya daha az meyilli alternatifler kullanmak isteği güçlü.

  • Birçok şirketin kendi ihtiyacına uygun çözümü birleştirerek kurduğunu görmek ilginç; özellikle baştan kendi stack’ini geliştirmek yerine ticarileşmiş açık kaynak araçlarla başlamalarını olumlu buluyorum. Ayrıca Tantivy aracılığıyla fark ettiğim Quickwit gözüme çarpan bir başka proje; Lucene tabanlı ES’ye benzer bir his bırakıyor: Quickwit GitHub linki

    • Tantivy’ydi :)

  • Rocks, Level’in bir çatallı sürümü; Level ise veri bozulması gibi bug’larıyla biliniyor. Her iki sistem de üretimde çokça kullanıldı, ama ben Level’i kullanırken operasyon ekibimin hizmetin sürekliliğini sağlamak için hata yönetiminde çok fazla çaba harcadığını gördüm. Böyle şirket bloglarında yeni stack’lerin dezavantajları veya ciddi sorunları dürüstçe anlatılmaz; “büyük isimli şirketlerin” teknik söylemleri de çoğu zaman şirket öyküsü pazarlamasıdır.

    • RocksDB zaten LevelDB’den yıllar önce ayrıldı ve sanayi ile akademide büyük ölçekte iyileştirmeler gördü; şimdi artık LevelDB gibi oyuncak bir veritabanı değil. Görmeyen bir kusuru olabilir ama RocksDB’de ciddi bir sorun bekleme olasılığı düşük.

    • Kendi deneyimim farklı: Son dört yıldır RocksDB’yi binlerce sunucuda (sunucu başına birkaç TB veri) çalıştırdım ve RocksDB’deki bir arıza ile karşılaşmadım.

  • “Elasticsearch” anahtar kelimesi nedeniyle bu yazıyı açtım; radar.com’u bilmediğimi görmek ilginçti. İhtiyacım olan uygun fiyatlı auto-complete özelliğini görünce ilgimi çekti.