- 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
nullet 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.
1 commentaires
Avis de Hacker News
Je trouve dommage qu'il manque des détails et qu'il n'y ait probablement pas de plan open source ; si vous avez cliqué ici en cherchant une alternative à ES (Elasticsearch), je recommande typesense.org et duckdb.org (en particulier avec le plugin spatial). Les deux offrent d'excellentes performances sur les données spatiales, et DuckDB semble très adapté pour une utilisation en production avec des données qui changent peu. Même dans des configurations cluster/sharding, elles sont complètement open source. C'est une recommandation basée uniquement sur mon expérience, sans autre lien.
Ces deux projets sont vraiment excellents ; notre équipe utilise déjà DuckDB de manière active pour les contrôles de data lake et des transformations de données simples. Nous prévoyons d'ajouter prochainement des articles de blog détaillant davantage des parties variées du système ; nous avons décidé de répartir le contenu, car trop d'informations dans un seul post devient difficile à lire.
Je suis toujours reconnaissant qu'il existe de tels projets open source, mais je ressens qu'il n'est pas simple de les intégrer à mon projet. J'ai déjà essayé de compiler en liaison statique duckdb, spatial et les extensions SQLite, puis j'ai découvert que la compilation échouait à cause de symboles SQLite de versions différentes, ce qui était pénible.
DuckDB n'a vraiment pas de sharding ni de clustering ? Il n'y a pas non plus de serveur séparé (mis à part l'extension HTTP Server).
Typesense a de très bonnes performances et l'expérience de développement est vraiment satisfaisante.
Je ne sais pas ce qui devrait être open source ici : est-ce du code Rust ? Ils annoncent une « DB », mais j'ai plutôt l'impression d'une description de stack complète.
Je trouve drôle qu'une page de recrutement affiche en premier avantage la « culture du travail au bureau » ; je me demande vraiment en quoi ça peut être un bénéfice.
Le problème n'est pas seulement le temps de trajet entre télétravail et commuting ; cela recouvre aussi l'environnement de travail, l'équilibre vie pro/vie perso, etc. Quand le déplacement dure moins de 30 minutes et se fait à pied ou à vélo, j'ai eu une expérience très agréable : on fait de l'exercice, on clarifie ses idées, et la transition entre la maison et le travail se fait naturellement. En 2020, quand je pratiquais le full remote, le fait de travailler et de se reposer dans le même espace devenait de plus en plus difficile, et marcher une heure chaque soir après le travail m'a beaucoup aidé mentalement. En revanche, les trajets quotidiens de plus d'une heure en transports publics ou sur autoroute ont été éprouvants.
Si la culture de bureau offre vraiment des avantages, il faut des opportunités d'apprentissage avec des personnes compétentes, de se faire des amis, de la nourriture/boisson gratuites, une machine à café, etc. Dans ma dernière expérience en bureau, il n'y avait absolument rien de tout cela, et l'ambiance ressemblait à un télétravail industrialisé, plutôt morose.
Certaines personnes peuvent aimer venir au bureau, cela dépend de chacun.
Je préfère commuter que travailler en remote, donc il existe sûrement des gens pour qui le trajet est un avantage.
Je me demande si ce système serait utile pour Photon, le moteur open source ElasticSearch/OpenSearch pour les données OSM (OpenStreetMap). L'expérience de recherche dans la plupart des applications OSM est plutôt mauvaise et fragile face aux fautes de frappe, alors Photon apporte une petite innovation sur ce point. Lien GitHub Photon
C'est une opinion un peu méta, mais il est agréable de voir revenir une dynamique autour de la conception de stockage maison et de moteur de requête, avec davantage d'articles de blog. Dans les années 2010, ce genre de vague avait déjà eu lieu, et récemment la tendance s'est concentrée sur l'AI.
Je pense que cette vague n'était pas due à l'AI, mais au fait que la plupart se sont révélées sans utilité. Puisqu'il est généralement possible d'atteindre les performances attendues en ajustant les systèmes existants ou en les étendant, des stacks maison trop spécialisées n'étaient finalement pas nécessaires. Un système de stockage/requêtes interne non destiné à être commercialisé finit souvent par être un symptôme de syndrome NIH (Not Invented Here) dans les entreprises qui disposent de ressources suffisantes.
Le NoSQL et les bases de données alternatives s'étaient un temps diffusés comme une mode, puis ils ont disparu quand il est devenu clair que PostgreSQL seul suffisait à la plupart des entreprises.
Je ne sais pas s'il reste encore de quoi innover ; je préfère un produit fiable et validé à des stockages de données expérimentaux.
Je trouve étrange que le mot-clé « Rust » soit inclus dans le titre ; un lecteur pourrait se demander ce que Rust remplace, Elasticsearch ou MongoDB.
Cet article manque cruellement de détails ; par exemple, la méthode de sharding des données, les décalages entre l'indexation et les services, la gestion des nœuds défaillants, la latence dans un système distribué et bien d'autres points clés sont absents.
En tant que personne dans le domaine de la recherche, j'observe avec intérêt combien d'entreprises visent aujourd'hui explicitement un « remplacement d'ElasticSearch ».
C'est l'auteur ! J'ai été motivé, côté exploitation, par la volonté de transformer un problème de « système distribué » en « système monolithique », et l'idée qu'on peut aujourd'hui le faire avec du hardware. J'ai donc choisi des systèmes de stockage embarqués comme RocksDB, Tantivy. Grâce au memory-mapping, cela permettait aussi de couvrir une échelle mondiale, et comme le cloud permet de scaler la RAM librement, le reindexation et la mise à jour étaient gérés simplement : réindexer entièrement sur un nouveau nœud avec le même binaire puis envoyer vers S3, sans avoir besoin de gérer séparément l'état actuel d'ES/Mongo.
J'ai souvent eu le sentiment que les efforts et le temps requis pour faire fonctionner et administrer un cluster Elasticsearch sont nettement plus importants que pour une vraie base de données en production. C'est pourquoi je suis de plus en plus enclin à utiliser des alternatives plus simples, avec moins de fonctionnalités que l'ES complet, moins sujettes à casser.
Il est intéressant de voir plusieurs entreprises assembler des solutions qui leur conviennent vraiment. Je trouve positif qu'elles aient démarré en utilisant des outils open source commerciaux plutôt qu'en développant une solution maison dès le départ ; à ce sujet, Quickwit repéré via Tantivy m'a interpellé, avec une approche proche d'ES basée sur Lucene. Lien GitHub Quickwit
Rocks est un fork de Level, et Level est bien connu pour des bugs comme la corruption de données ; les deux systèmes ont été très utilisés en production, mais quand j'ai utilisé Level, l'équipe d'opérations a dû fournir énormément d'efforts pour maintenir le service face aux erreurs. Les articles de blog d'entreprises ne disent jamais franchement les faiblesses ou les problèmes graves d'une stack nouvelle ; même les tech talks des « big names » finissent par être de la publicité pour leur propre histoire.
RocksDB s'est séparé de LevelDB il y a longtemps et bénéficie désormais d'améliorations massives dans l'industrie et la recherche ; je pense que ce n'est plus une base de données jouet comme LevelDB. Peut-être reste-t-il des défauts non découverts, mais je pense que le risque d'avoir un gros problème avec RocksDB est faible.
Mon expérience est différente : pendant 4 ans, j'ai exécuté RocksDB sur des milliers de serveurs (plusieurs téraoctets par serveur) sans que RocksDB ne rencontre d'erreur.
C'est parce que le mot-clé Elasticsearch m'a poussé à cliquer que je suis tombé sur cet article, sans connaître radar.com, ce qui m'a surpris. J'ai été attiré car je vois une fonctionnalité d'autocomplétion à un prix qui m'intéresse.