Wie Elasticsearch und MongoDB durch Rust und RocksDB ersetzt wurden

• Radar bietet eine Geoinformations-Infrastruktur, die täglich mehr als eine Milliarde API-Anfragen verarbeitet, und wechselte von Elasticsearch und MongoDB zu der selbstentwickelten HorizonDB, um Probleme bei Performance und Skalierbarkeit zu lösen
• HorizonDB wurde in Rust entwickelt und ist eine leistungsstarke Geodatenbank, die verschiedene Open-Source-Tools wie RocksDB, S2, Tantivy, FST, LightGBM und FastText kombiniert
• In der bisherigen Struktur waren die Skalierungskosten und die Komplexität von Elasticsearch und MongoDB hoch, was den Betrieb erschwerte
• HorizonDB basiert auf einem einzelnen Multi-Thread-Prozess und erreicht dadurch Kostenersparnis, Leistungsverbesserung und hohe Zuverlässigkeit
• Insgesamt verbesserten sich Entwicklungsproduktivität und Betriebseffizienz deutlich, sodass neue Daten oder Funktionen schnell übernommen werden konnten
• Die Daten werden nach der Verarbeitung mit Apache Spark versioniert in AWS S3 gespeichert; Entwickler können sie auch lokal einfach ausführen und testen
• Dadurch wurden große MongoDB- und Elasticsearch-Cluster abgeschaltet, die Kosten deutlich reduziert und sowohl die Feature-Entwicklungsgeschwindigkeit als auch die Datenträgerverarbeitungseffizienz verbessert

---

Einführung und Hintergrund

• Radar ist eine Geo-Lokations-Infrastrukturplattform, die täglich mehr als eine Milliarde API-Calls für hunderte Millionen Geräte weltweit verarbeitet
  • Wichtige APIs sind unter anderem Geocoding, Search, Routing, Geolocation compliance
• Mit dem Wachstum von Datenvolumen und Produktumfang wurde die Lösung von Performance-, Skalierbarkeits- und Kostenthemen dringend erforderlich
• Aus diesem Grund wurde die in Rust geschriebene HorizonDB eingeführt, die verschiedene Standortdienstleistungen aus einem hochperformanten Binärpaket bereitstellt
  • 1.000 QPS pro Kern
  • mittlere Latenz bei Forward Geocoding: 50 ms, Reverse Geocoding < 1 ms
  • lineare Skalierung auf Standardhardware

Grenzen der bisherigen Architektur

• Vorherige Struktur: Forward Geocoding lief über Elasticsearch, Reverse Geocoding über MongoDB
• Probleme:
  • Elasticsearch verteilt Abfragen auf alle Shards und erfordert regelmäßige Batch-Updates
  • Bei MongoDB ist das Einspeisen großer Batches schwierig, außerdem sind übermäßige Ressourcenzuweisung und ein zuverlässiger Rollback-Mechanismus nicht vorhanden

Ziele der HorizonDB-Architektur

• Effizienz – Laufzeit auf Standardhardware, voraussagbares Autoscaling, dient als einzige Datenquelle für alle Geo-Entitäten
• Betriebstauglichkeit – tägliches mehrmaliges Bauen und Verarbeiten der Datenbestände, einfache Änderungen und Rollbacks, vereinfachter Betrieb
• Entwicklererlebnis – lokale Ausführung möglich, Änderungen und Tests sind einfach

Verwendeter Technologie-Stack

RocksDB, S2, Tantivy, FSTs, LightGBM und FastText werden kombiniert, während die Daten nach der Vorverarbeitung mit Apache Spark von einer Rust-Komponente als versionierte Dateien in S3 gespeichert werden

• Rust

  • Eine von Mozilla entwickelte Systemprogrammiersprache
  • Garantiert Kompilier- und Speicher-Sicherheit, ermöglicht vorhersagbare Verwaltung großer Indexspeicher ohne Garbage Collection
  • Nullbehandlung, Pattern Matching und weitere hochniveaus Abstraktionen erleichtern die Abbildung komplexer Ranking-Logiken in der Suche
  • Ein einziger Multi-Thread-Prozess optimiert die Verarbeitung von Hunderten von GB an Daten auf SSDs

• RocksDB

  • Leistungsstarker, auf LSM-Tree basierender In-Process-Speicher
  • Reaktionszeiten im Mikrosekundenbereich, stabile Performance auch bei großen Datenmengen

• S2

  • Räumliche Indexbibliothek von Google, die die Erde in Quadranten aufteilt, um Punkt-zu-Polygon-Abfragen zu beschleunigen
  • Radar entwickelte eigene Rust-Bindings für die C++-S2-Bibliothek, die bald Open Source verfügbar gemacht werden

• FSTs (Finite State Transducers)

  • Effiziente Datenstruktur für String-Kompression und Prefix-Suche
  • Berücksichtigt, dass 80 % der Abfragen dem regulären „happy path“ folgen, sodass mit wenigen MB RAM hunderte Millionen Pfade gecacht werden können

• Tantivy

  • In-Process-Inverted-Index-Bibliothek ähnlich wie Lucene
  • Gründe für die Einführung statt eines externen Dienstes wie Elasticsearch:
    • Suchqualität – Reaktion auf fortgeschrittene Suchvorgänge wie dynamische Keyword-Erweiterung ohne zusätzliche Kommunikationslatenz
    • Betriebsvereinfachung – Verarbeitung innerhalb eines einzelnen Prozesses, Skalierung auch für große Indizes durch einfache Memory-Mapping-Nutzung

• FastText

  • Ein mit eigenem Korpus und Logs trainiertes FastText-Modell erzeugt Wortvektorrepräsentationen für den Einsatz in ML-Anwendungen
  • Robust gegenüber Tippfehlern und nicht registrierten Wörtern, semantische Ähnlichkeit benachbarter Vektoren ermöglicht semantisches Suchverständnis

• LightGBM

  • Einsatz zahlreicher LightGBM-Modelle für Query-Intent-Klassifikation, Attribut-Tagging innerhalb von Abfragen
  • Beispiel: Bei Regionalanfragen wie „New York“ wird die Adresssuche übersprungen, bei „841 Broadway“ wird die POI-/Regionsuche übersprungen

• Apache Spark

  • Schnelle Verarbeitung von mehreren hundert Millionen Datenpunkten innerhalb einer Stunde, kontinuierliche Pipeline-Optimierung zur Verbesserung von Join- und Aggregations-Performance
  • Die Enddaten werden in S3 gespeichert und können mit SQL-basierten Abfragen über Amazon Athena oder DuckDB analysiert werden

Ergebnisse der Einführung von HorizonDB

• Der Dienst wurde deutlich schneller, der Betrieb vereinfacht und die Zuverlässigkeit verbessert
• Das Entwicklungsteam kann neue Funktionen und Datenquellen innerhalb eines Tages ausrollen und validieren
• Die Abschaltung großer Mongo- und Elasticsearch-Cluster sowie mehrerer Microservices spart pro Monat mehrere zehntausend Dollar

• Radar ist nun auf künftige großangelegte Skalierung vorbereitet. Der Ablauf der Entwicklung einzelner Funktionen wird in einem zukünftigen Blogbeitrag vorgestellt