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

[GN⁺]

Hacker News Kommentar

• Ich finde es schade, dass es nicht genug Details gibt und auch kein echter Open-Source-Plan erkennbar ist. Falls ich diesen Beitrag beim Suchen nach einer ES(ElasticSearch)-Alternative angeklickt hätte, würde ich typesense.org und duckdb.org (vor allem mit dem spatial-Plugin) empfehlen: Beide Dienste liefern starke Performance bei räumlichen Daten, und DuckDB wirkt für produktive Einsätze mit relativ stabilen Daten sehr passend. Selbst im Cluster-/Sharding-Setup ist alles vollständig Open Source. Das ist eine reine, rein erfahrungsbasierte Empfehlung.

  • Beide Projekte sind wirklich großartig. Unser Team nutzt DuckDB aktiv für Data-Lake-Prüfungen und einfache Datenaufbereitung. Wir planen, künftig Blogposts zu schreiben, die verschiedene Teile des Systems genauer erklären; einen einzelnen Post mit zu vielen Inhalten halte ich für schwer lesbar.
  • Ich bin dankbar, dass es solche Open-Source-Projekte gibt, aber ich habe das Gefühl, dass die Integration in eigene Projekte nicht so einfach ist. Früher habe ich versucht, duckdb samt spatial und SQLite-Erweiterungen statisch zu verlinken und zu bauen, bis mir klar wurde, dass Builds wegen unterschiedlicher SQLite-Symbole je nach Version scheitern.
  • DuckDB hat wirklich gar kein Sharding oder Clustering, oder? Und es gibt keinen eigenen Server (außer der HTTP Server Extension).
  • Typesense ist wirklich top in Sachen Performance, und die Entwicklungserfahrung ist ebenfalls sehr gut.
  • Ich weiß nicht genau, was hier Open Source werden soll: der Rust-Code? Es wird als DB bezeichnet, wirkt aber eher wie eine Beschreibung des kompletten Stacks.

• Es wirkt irgendwie lustig, dass auf der Jobseite als erster Benefit „Office-Kultur“ genannt wird; ich bin wirklich neugierig, wie Pendeln dabei ein Vorteil sein soll.

  • Pendeln versus Homeoffice umfasst mehr als nur die Fahrzeit: Arbeitsumfeld, Work-Life-Balance und andere Faktoren spielen ebenfalls eine Rolle. Als die Pendelzeit unter 30 Minuten lag und man zu Fuß oder mit dem Fahrrad fahren konnte, war es wirklich angenehm: Man bewegt sich, ordnet seine Gedanken und schafft einen klaren Wechsel zwischen Zuhause und Arbeit. 2020, als ich komplett im Homeoffice war, wurde es immer schwerer, in derselben Umgebung zu arbeiten und sich auszuruhen; deshalb bin ich täglich nach Feierabend eine Stunde lang spazieren gegangen und habe mich geistig deutlich erholt. Pendeln über mehr als eine Stunde – ob mit öffentlichem Verkehr oder auf der Autobahn – war jedoch hart.
  • Eine echte Office-Kultur ist für mich erst dann ein echter Vorteil, wenn es gute Lerngelegenheiten mit schlauen Leuten, Networking, kostenloses Essen/Trinken, eine DDR-Maschine usw. gibt. In meiner letzten Büroumgebung gab es genau diese Vorteile nicht; es fühlte sich eher wie eine skalierte Version von Homeoffice an, mit eher depressiver Stimmung.
  • Manche mögen es vielleicht, ins Büro zu fahren; das ist individuell verschieden.
  • Ich bevorzuge Pendeln gegenüber Homeoffice – also es gibt auf jeden Fall Leute, für die „Pendeln ein Vorteil“ ist.

• Ich frage mich, ob dieses System für Photon, die Open-Source-ElasticSearch/OpenSearch-Engine für OSM(OpenStreetMap)-Daten, hilfreich wäre. Die Suche in den meisten OSM-Apps ist eher schwach und fehleranfällig bei Tippfehlern, Photon bringt hier eine kleine Verbesserung. Photon GitHub-Link

  • In diesem Fall halte ich ein auf LMDB aufgebautes System für passender als RocksDB. OSM Express nutzt bereits LMDB, siehe OSM Express Wiki-Link

• Meta: Es ist schön zu sehen, dass wieder wiederholt über eigene Datenspeicher und Query-Engine-Design in Blogposts geschrieben wird. In den 2010ern gab es genau so einen Run, zuletzt war der Fokus auf KI gerichtet.

  • Ich denke, dieser Run war nicht wegen KI, sondern weil sich herausgestellt hat, dass der Großteil nichts bringt. Mit Tuning oder Skalierung bestehender Systeme lässt sich die Performance oft ausreichend erreichen, sodass übermäßig spezialisierte Eigen-Stacks am Ende nicht erforderlich waren. Ein internes, nicht als Produkt geplantes Storage-/Query-System ist oft ein NIH(Not Invented Here)-Syndrom mit viel Ressourcen.
  • NoSQL/Alternative Datenbanken hatten einst einen Hype wie einen Trend, der abgeflaut ist, nachdem klar wurde, dass für die meisten Unternehmen PostgreSQL alleine reicht.
  • Ich weiß nicht, ob da noch genug Innovation übrig ist; ich will verlässliche, bewährte Produkte statt experimenteller Datastores.

• Dass das Wort „Rust“ im Titel steht, wirkt seltsam. Als Leser kann es unklar sein, was Rust hier eigentlich ersetzt – ElasticSearch oder MongoDB.

• Dieser Artikel hat zu wenig Details, etwa fehlen wichtige Punkte wie Daten-Sharding-Methodik, Latenz zwischen Indexierung und Service-Update, Fehlerbehandlung bei ausgefallenen Nodes und die Latenz in verteilten Systemen.

• Aus der Suche-Sicht ist es interessant zu beobachten, wie viele Firmen derzeit „ElasticSearch als Ersatz“ als Ziel haben.

  • Ich bin der Autor dieses Beitrags. Aus Betriebsgründen war ich motiviert, ein „verteiltes System“-Problem zu einem „monolithischen System“ zu machen, weil ich dachte, dass man mit heutiger Hardware viel erreichen kann. Deshalb habe ich mich für eingebettete Speicher wie RocksDB und Tantivy entschieden. Durch Memory Mapping konnten wir sogar einen globalen Bedarf abdecken, und in der Cloud ist das Aufrüsten von RAM flexibel. Backfills und Updates werden simpel gehandhabt: statt ES/Mongo für den aktuellen Zustand separat zu kümmern, wird auf einem neuen Node mit demselben Binary vollständig neu indexiert und dann nach S3 übertragen.
  • Der Aufwand und die Zeit für den Betrieb eines Elasticsearch-Clusters haben sich oft deutlich größer angefühlt als für eine normale Produktionsdatenbank. Genau deshalb habe ich oft den Wunsch, in vielen Fällen auf einfachere Alternativen umzusteigen, die weniger Funktionen statt des kompletten ES-Funktionsumfangs bieten und weniger kaputtgehen.

• Es ist interessant zu sehen, wie viele Unternehmen maßgeschneiderte Lösungen kombinieren; gerade positiv finde ich, dass sie lieber mit fertigen Open-Source-Tools starten als bei Null eine Eigenlösung zu entwickeln. Apropos: Quickwit, das ich durch Tantivy entdeckt habe, ist mir ins Auge gefallen; es fühlt sich an wie ES auf Lucene-Basis. Quickwit GitHub-Link

  • tantivy eben. :)

• Rocks ist ein Fork von LevelDB, und Level ist bekannt für Bugs wie Datenkorruption. Beide Systeme wurden stark in der Produktion eingesetzt; als ich Level genutzt habe, hat das Ops-Team enorme Mühe gehabt, Fehlerbehandlung zu betreiben, um den Service am Laufen zu halten. Solche Firmen-Blogposts sagen selten ehrlich die Nachteile oder gravierende Probleme neuer Stacks; Tech-Talks von „Big Name“-Unternehmen sind am Ende meist selbstvermarktete Firmengeschichten.

  • RocksDB ist schon lange von LevelDB abgespalten und seitdem in Industrie und Wissenschaft massiv verbessert; ich würde es nicht mehr als „Toy-DB“ im Sinne von LevelDB sehen. Es könnte noch unerkannte Nachteile geben, aber ich glaube, dass bei RocksDB schwerwiegende Probleme eher unwahrscheinlich sind.
  • Meine eigene Erfahrung ist eine andere: Ich habe in den letzten vier Jahren RocksDB auf tausenden Servern (mehrere Terabyte pro Server) betrieben, ohne dass in RocksDB selbst ein Fehler auftrat.

• Ich habe wegen des Keywords „Elasticsearch“ geklickt und fand es erstaunlich, dass ich radar.com nicht kannte; ich habe Interesse entwickelt, weil ich eine Autocomplete-Funktion zu einem für mich passenden Preis gefunden habe