Comment nous avons remplac� Elasticsearch et MongoDB par Rust et RocksDB, par Radar

Comment nous avons remplac� Elasticsearch et MongoDB par HorizonDB avec Rust et RocksDB pour am�liorer les performances, par Radar

Chez Radar, la performance est une fonctionnalit�. Notre plateforme traite plus d'un milliard d'appels API par jour provenant de centaines de millions d'appareils � travers le monde. Nous fournissons une infrastructure et des solutions de g�olocalisation, notamment des API pour :

• G�ocodage : API de g�ocodage direct, de g�ocodage invers� et de g�ocodage IP avec une couverture mondiale.
  
• Recherche : API de saisie semi-automatique d'adresses, de validation d'adresses et de recherche de lieux.
  
• Routage : API de distance, de matrice, d'optimisation d'itin�raire, de correspondance d'itin�raire et d'itin�raires.
  
• Conformit� en mati�re de g�olocalisation : d�tection de la juridiction actuelle, de la distance par rapport � la fronti�re, des zones d'exclusion r�glementaires, etc.

Mais � mesure que nos produits et nos donn�es �voluent, nos d�fis techniques �voluent �galement.

Pour soutenir cette croissance, nous avons d�velopp� HorizonDB, une base de donn�es g�ospatiale �crite en Rust qui consolide plusieurs services de localisation en un seul binaire hautement performant. Avec HorizonDB, nous sommes en mesure de prendre en charge tous les cas d'utilisation ci-dessus avec une excellente empreinte op�rationnelle :

• G�rer 1 000 QPS par c�ur.
  
• Maintenir une latence m�diane de g�ocodage direct de 50 ms.
  
• Maintenir une latence m�diane de g�ocodage inverse inf�rieure � 1 ms.
  
• �voluer de mani�re lin�aire sur du mat�riel standard.

Pourquoi nous avons remplac� Mongo et Elasticsearch

Avant HorizonDB, nous r�partissions le g�ocodage entre Elasticsearch et des microservices pour le g�ocodage direct, et MongoDB pour le g�ocodage inverse.

L'exploitation et la mise � l'�chelle de cette pile �taient co�teuses : Elasticsearch diffusait fr�quemment les requ�tes � tous les shards et n�cessitait des mises � jour par lots orchestr�es par le service, tandis que MongoDB ne disposait pas d'une v�ritable ingestion par lots, n�cessitait un surprovisionnement et ne disposait pas d'une fonctionnalit� fiable de restauration en masse pour les donn�es erron�es.

L'architecture

Nos objectifs pour ce service �taient les suivants :

1. Efficacit� : le service peut fonctionner sur des machines standard, dispose d'une mise � l'�chelle automatique pr�visible et constitue la source unique de v�rit� pour toutes nos entit�s g�ographiques.
   
2. Op�rations : les ressources de donn�es peuvent �tre cr��es et trait�es plusieurs fois par jour, les modifications peuvent �tre d�ploy�es et annul�es facilement, et le service doit �tre simple � utiliser.
   
3. Exp�rience des d�veloppeurs : les d�veloppeurs doivent pouvoir ex�cuter le service localement, et les modifications doivent pouvoir �tre �crites et test�es facilement.

Avec ces objectifs � l'esprit, nous avons cr�� HorizonDB � l'aide de RocksDB, S2, Tantivy, FSTs, LightGBM et FastText.

Les ressources de donn�es sont pr�trait�es � l'aide d'Apache Spark, ing�r�es dans Rust et stock�es sous forme de ressources versionn�es dans AWS S3.

Figure 1 : Le serveur HorizonDB est un processus multithread unique qui interroge simultan�ment diff�rentes � couches � et reclassifie les candidats de mani�re uniforme.

Rust

Un langage compil� con�u par Mozilla pour la programmation syst�me. L'�quipe a appr�ci� de nombreux aspects de Rust :

• Compilation et s�curit� de la m�moire sans ramasse-miettes : le syst�me de types forts de Rust et la concurrence s�re et expressive sous la forme de Rayon et Tokio nous permettent d'�crire du code performant sans sacrifier la lisibilit�. Rust facilite la gestion de la m�moire sans ramasse-miettes, ce qui nous permet de g�rer de grands index de donn�es en m�moire avec une latence pr�visible.
  
  
• Abstractions d'ordre sup�rieur : bon nombre de nos ing�nieurs travaillent avec des langages de haut niveau o� les op�rations de liste expressives, la gestion des valeurs nulles et la correspondance de motifs sont monnaie courante. Rust dispose de ces primitives, ce qui permet � notre �quipe d'avancer rapidement et d'exprimer clairement la logique, ce qui est important lorsqu'il s'agit de logique complexe telle que le classement des recherches.
  
  
• Multithread et non multiprocessus : HorizonDB devant r�cup�rer des centaines de Go de donn�es � partir de SSD, il est plus efficace d'avoir un seul processus pouvant exploiter le m�me espace d'adressage m�moire que notre langage de couche API TypeScript d�ploy� sur Node.js, qui consacre un nouveau processus � chaque c�ur.

RocksDB

Un arbre LSM (Log-Structured Merge) en cours de traitement, qui sert de stockage principal pour nos enregistrements. Il est incroyablement rapide, avec des temps de r�ponse g�n�ralement de l'ordre de la microseconde (m�me avec un ensemble de donn�es beaucoup plus volumineux, il est plus rapide que d'autres solutions hautes performances).

S2

S2 est la biblioth�que d'indexation spatiale de Google qui projette un arbre quadratique sur une sph�re, transformant les recherches O(n) point-dans-polygone en recherches en temps constant pouvant �tre mises en cache. Lors de l'�criture de HorizonDB, nous avons �crit des liaisons Rust pour la biblioth�que C++ de Google que nous rendrons bient�t open source.

FST

Les FST sont une structure de donn�es offrant une compression efficace des cha�nes de caract�res et des requ�tes de pr�fixe. Cet article de blog d'Andrew Gallant d�crit en d�tail comment cela est r�alis�. Nous avons constat� que 80 % de nos requ�tes �taient bien form�es et nous voulions trouver un moyen efficace de mettre en cache ces � chemins heureux �. Gr�ce aux FST, nous avons pu mettre en cache des millions de ces chemins heureux sur plusieurs Mo de m�moire et souvent renvoyer des candidats de pr�fixe en quelques millisecondes.

Figure 2 : Un FST repr�sente de mani�re compacte un corpus de mots en compressant les pr�fixes et suffixes courants. Les FST sont �galement capables d'encoder des valeurs num�riques qui peuvent �tre r�cup�r�es lors du parcours, ce qui nous permet de compresser des m�tadonn�es telles que la latitude et la longitude � des fins de classement.

Tantivy

Une biblioth�que d'index invers� en cours de traitement similaire � Lucene.

Nous avons d�cid� d'utiliser un index en cours de traitement plut�t qu'un service externe tel qu'Elasticsearch ou Meilisearch pour plusieurs raisons :

• Qualit� de la recherche : afin d'am�liorer notre rappel pour des cas d'utilisation tels que la validation d'adresses, nous � �largissons � souvent nos mots-cl�s de recherche de mani�re dynamique. Cela se traduirait par l'envoi de plusieurs requ�tes sur le r�seau si nous utilisions un service externe.
  
  
• Simplicit� op�rationnelle : tout se trouve dans le m�me processus, ce qui facilite consid�rablement la mise � l'�chelle des serveurs de recherche. Le mappage m�moire nous permet d'utiliser efficacement du mat�riel standard avec des index volumineux. Nous avons trouv� cela beaucoup plus simple que la mise � l'�chelle d'Elasticsearch, o� il �tait tr�s difficile de r�gler les param�tres JVM et d'essayer de saturer le CPU sans augmenter la latence.

Figure 3 : un index invers� (par opposition � un index direct classique comme dans une base de donn�es SQL) permet de trouver de mani�re performante les documents pertinents en fonction des termes recherch�s. Les identifiants des documents peuvent �tre compress�s � l'aide de techniques telles que le codage delta. La requ�te � Central Park � peut �tre trait�e de mani�re performante en interrogeant et en combinant les documents renvoy�s par les termes � central � et � park �.

FastText

Afin d'am�liorer la pr�cision et la qualit� de la recherche, nous avons mis en �uvre un mod�le FastText form� � partir d'un m�lange de notre corpus de g�ocodeurs et de nos journaux de requ�tes. Avec FastText, nous pouvons repr�senter s�mantiquement les mots d'une requ�te sous forme de vecteurs num�riques, adapt�s aux applications d'apprentissage automatique. FastText tol�re les fautes de frappe et g�re les mots hors vocabulaire gr�ce � l'utilisation de ngrams. Les vecteurs � proches � repr�sentent des mots s�mantiquement similaires, ce qui permet � nos algorithmes d'apprentissage automatique de comprendre la s�mantique d'un mot donn� dans une requ�te de recherche.

LightGBM

Nous avons form� plusieurs mod�les LightGBM pour classer l'intention des requ�tes et baliser certaines parties de nos requ�tes en fonction de cette intention. Cela nous permet de � structurer � nos requ�tes, am�liorant ainsi les performances et la pr�cision de la recherche. Par exemple, une requ�te consid�r�e comme r�gionale, telle que � New York �, peut ignorer la recherche d'adresse, tandis qu'une requ�te telle que � 841 broadway � nous permet d'ignorer la recherche de points d'int�r�t et de r�gions.

Apache Spark

Avec Spark, nous sommes en mesure de traiter des centaines de millions de points de donn�es en moins d'une heure, avec une �volutivit� quasi lin�aire. Nous devions souvent ajuster ou refactoriser les t�ches pour obtenir des performances optimales lors des jointures ou des agr�gations.

Comme nos donn�es sont �crites dans S3, il devient facile d'inspecter les r�sultats via Amazon Athena, un d�ploiement h�berg� d'Apache Presto qui peut lire les ressources de stockage d'objets � l'aide de SQL. DuckDB est un autre outil l�ger que nos ing�nieurs utilisent pour inspecter ces ressources � la vol�e.


R�sultats

HorizonDB a transform� � la fois les aspects op�rationnels et d�veloppementaux de nos offres de g�olocalisation. Nous avons obtenu des am�liorations g�n�rales en termes de co�t, de performances et d'�volutivit� :

• Notre service est d�sormais plus rapide, plus simple � utiliser et plus fiable.
  
• Nos d�veloppeurs sont en mesure de r�agir rapidement aux nouvelles fonctionnalit�s et aux modifications des donn�es. Nous sommes capables d'ing�rer et d'�valuer de nouvelles sources de donn�es en moins d'une journ�e.
  
• Nous avons ferm� plusieurs clusters Mongo, un grand cluster Elasticsearch et plusieurs microservices g�ographiques, ce qui nous a permis d'�conomiser plusieurs dizaines de milliers de dollars en co�ts mensuels.

Nous sommes satisfaits de nos choix de conception avec HorizonDB et sommes pr�ts � �voluer dans un avenir proche. Nous aborderons la mani�re dont nous avons con�u certaines fonctionnalit�s du syst�me dans de futurs articles de blog.

Un grand merci � nos ing�nieurs Bradley Schoeneweis, Jason Liu, Jacky Wang, Binh Robles, Greg Sadetsky, David Gurevich et Felix Li, qui ont travaill� d'arrache-pied pour faire de ce syst�me une r�alit�.

� propos de Radar

Radar relie les mondes num�rique et physique gr�ce � une infrastructure de localisation pour chaque produit et service. La soci�t� a �t� fond�e en 2016 par Nick Patrick et Coby Berman, deux anciens coll�gues de Foursquare qui ont dix ans d'exp�rience dans la cr�ation et la vente de produits et services bas�s sur la localisation.

Source : Radar

Et vous ?

Pensez-vous que cette d�claration est cr�dible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Comment nous avons �conomis� 98 % des co�ts du cloud en �crivant notre propre base de donn�es, par Hivekit

Red�finir la base de donn�es pour l'IA : pourquoi MongoDB a acquis Voyage AI, par Dev Ittycheria, PDG de MongoDB

Elasticsearch est � nouveau open source, en ajoutant l'AGPL, conforme � l'OSI, comme troisi�me option, apr�s trois ans o� les produits d'Elastic ne poss�daient qu'une double-licence non open source