Comment Radar a remplacé Elasticsearch et MongoDB par Rust et RocksDB

• Radar exploite une infrastructure géospatiale traitant plus d'un milliard de requêtes API par jour et a migré d'Elasticsearch et MongoDB vers HorizonDB, sa solution interne, pour résoudre des problèmes de performance et de scalabilité.
• HorizonDB est développé en Rust et combine des outils open source comme RocksDB, S2, Tantivy, FST, LightGBM et FastText pour former une base de données géospatiale haute performance.
• Dans l'ancienne architecture, l'augmentation des coûts et de la complexité d’extension d’Elasticsearch et MongoDB rendait l’exploitation difficile.
• HorizonDB fonctionne en processus unique multithreadé et atteint une réduction des coûts, une amélioration des performances et une fiabilité plus élevée.
• Globalement, la productivité de développement et l’efficacité opérationnelle se sont nettement améliorées, rendant possible l’application rapide de nouvelles données et de nouvelles fonctionnalités.
• Les données sont prétraitées avec Apache Spark, puis stockées par version dans AWS S3 ; les développeurs peuvent les exécuter et les tester facilement en local.
• Les clusters Mongo et Elasticsearch ont ainsi pu être fermés, avec une forte réduction des coûts, tout en améliorant la vitesse de développement des fonctionnalités et l’efficacité du traitement des données.

---

Introduction et contexte

• Radar est une plateforme d'infrastructure de géolocalisation qui traite plus d'un milliard d'appels API par jour sur des centaines de millions d'appareils dans le monde.
  • API principales : Geocoding, Search, Routing, Geolocation compliance
• Avec la montée en charge des données et du produit, la résolution des enjeux de performance, scalabilité et coût est devenue urgente.
• Pour cela, Radar a adopté HorizonDB écrit en Rust, qui regroupe plusieurs fonctions de services de localisation dans un seul binaire haute performance.
  • 1 000 QPS par cœur
  • 50 ms de latence médiane pour le geocoding direct, < 1 ms pour le geocoding inverse
  • Scalabilité linéaire sur du matériel standard

Limites de l'ancien système

• Ancienne architecture : le geocoding direct passait par Elasticsearch, le geocoding inverse par MongoDB.
• Problèmes :
  • Elasticsearch répartit les requêtes sur tous les shards et nécessite des mises à jour batch périodiques.
  • MongoDB rend difficile l'ingestion de gros lots, et présente une allocation excessive de ressources avec une absence de rollback fiable.

Objectifs de l'architecture HorizonDB

• Efficacité - Fonctionner sur du matériel générique, proposer un autoscaling prévisible et servir de source unique de données pour toutes les entités géographiques.
• Opérationnalité - Construire et traiter les actifs de données plusieurs fois par jour, faciliter les changements et les rollbacks, simplifier l’exploitation.
• Expérience développeur - Exécution possible en local, modifications et tests simplifiés

Stack technologique utilisée

RocksDB, S2, Tantivy, FSTs, LightGBM et FastText sont utilisés ensemble, tandis que les données sont prétraitées avec Apache Spark puis stockées en fichiers versionnés sur S3 via Rust.

• Rust

  • Langage de programmation système développé par Mozilla.
  • Il garantit la sécurité de compilation et de mémoire, et permet une gestion mémoire prédictible pour de très grands index sans garbage collection.
  • Les abstractions de haut niveau, notamment la gestion des null et le pattern matching, permettent de modéliser plus facilement des logiques complexes de ranking de recherche.
  • Optimisé pour traiter des centaines de Go de données sur SSD avec un processus unique multithreadé.

• RocksDB

  • Stockage in-process haute performance basé sur un arbre LSM
  • Réponses au niveau microseconde et vitesse stable, même sur de gros volumes de données.

• S2

  • Bibliothèque d’indexation spatiale de Google qui divise la Terre en quadrants pour accélérer les requêtes point-polygone.
  • Radar a développé en interne un binding Rust de la bibliothèque C++ S2, qui sera bientôt publié en open source.

• FSTs (Finite State Transducers)

  • Structure de données de compression de chaînes et de recherche par préfixe efficace.
  • Elle reflète le fait que 80 % des requêtes suivent un « happy path » régulier, permettant de mettre en cache des millions de chemins avec seulement quelques Mo de mémoire.

• Tantivy

  • Bibliothèque d'index inversé in-process, similaire à Lucene
  • Raisons de l'adoption plutôt qu'un service externe comme Elasticsearch :
    • Qualité de recherche - prise en charge de traitements avancés comme l'extension dynamique de mots-clés, sans latence de communication inter-processus.
    • Simplification opérationnelle - traitement au sein d'un seul processus et extension facile d'index volumineux grâce au memory mapping.

• FastText

  • Modèles FastText entraînés sur des corpus internes et des logs propres sont utilisés pour générer des représentations vectorielles de mots, puis intégrés à des usages ML.
  • Solides face aux fautes de frappe et aux mots hors vocabulaire, ils exploitent la similarité sémantique des vecteurs voisins pour permettre une compréhension sémantique de la recherche.

• LightGBM

  • Plusieurs modèles LightGBM sont utilisés, notamment pour la classification de l'intention de requête et le tagging d'attributs dans la requête.
  • Ex. : pour une requête locale comme « New York », la recherche d'adresse est ignorée ; pour « 841 Broadway », la recherche POI/région est également ignorée.

• Apache Spark

  • Traitement en moins d'une heure de plusieurs centaines de millions de points de données, avec amélioration continue des jobs pour de meilleures performances de jointures et d’agrégations.
  • Les données finales sont stockées sur S3, permettant une exploration des résultats en SQL via Amazon Athena ou DuckDB.

Résultats de l'adoption de HorizonDB

• Le service est devenu nettement plus rapide, plus simple à exploiter, et la fiabilité s'est améliorée.
• L’équipe de développement peut appliquer et évaluer en une journée de nouvelles fonctionnalités et de nouvelles sources de données.
• La fermeture de grands clusters Mongo, Elasticsearch et de plusieurs microservices a permis d'économiser plusieurs dizaines de milliers de dollars par mois.

• Radar est prêt pour des montées en charge à plus grande échelle. Les détails de la conception de certaines fonctionnalités seront présentés dans un prochain billet de blog.