Comment nous avons économisé 98 % des coûts du cloud en écrivant notre propre base de données

Par Hivekit

Quelle est la première règle en programmation ? Peut-être quelque chose comme "ne vous répétez pas" ou "si ça marche, n'y touchez pas" ? Ou encore "n'écrivez pas votre propre base de données"... C'est en effet une bonne règle.

Les bases de données sont un cauchemar à écrire, des exigences en matière d'atomicité, de cohérence, d'isolation et de durabilité (ACID) au partage, en passant par la récupération des erreurs et l'administration, tout est d'une difficulté inouïe.

Heureusement, il existe des bases de données extraordinaires qui ont été perfectionnées pendant des décennies et qui ne coûtent pas un centime. Alors pourquoi diable serions-nous assez fous pour en écrire une à partir de zéro ?


Eh bien, voici ce qu'il en est...

Hivekit exploite une plateforme cloud qui suit des dizaines de milliers de personnes et de véhicules en même temps. Chaque mise à jour de localisation est stockée et peut être récupérée via une API d'historique.

Le nombre de véhicules connectés simultanément et la fréquence de leurs mises à jour de localisation varient considérablement dans le temps, mais avoir environ 13 000 connexions simultanées, chacune envoyant environ une mise à jour par seconde, est assez normal.

Les clients de Hivekit utilisent ces données de manières très différentes. Certains cas d'utilisation sont très grossiers, par exemple lorsqu'une société de location de voitures souhaite afficher un aperçu de l'itinéraire emprunté par un client au cours de la journée. Ce type d'exigence pourrait être traité avec 30 à 100 points de localisation pour un trajet d'une heure, ce qui permettrait d'agréger et de compresser fortement les données de localisation avant de les stocker.

Mais il existe de nombreux autres cas d'utilisation pour lesquels cette option n'est pas envisageable. Les entreprises de livraison qui veulent pouvoir rejouer les secondes exactes qui ont précédé un accident. Les mines dotées de systèmes de localisation très précis sur site qui souhaitent générer des rapports indiquant quel travailleur a pénétré dans telle ou telle zone restreinte - à un demi-mètre près.

Ainsi, étant donné que le niveau de granularité dont chaque client aura besoin n'est pas connu à l'avance, chaque mise à jour de l'emplacement est stockée. Avec 13 000 véhicules, cela représente 3,5 milliards de mises à jour par mois, et ce chiffre ne fera qu'augmenter. Jusqu'à présent, Hivekit a utilisé AWS Aurora avec l'extension PostGIS pour le stockage des données géospatiales. Mais Aurora coûte déjà plus de 10 000 dollars par mois, rien que pour la base de données, et ce coût ne fera qu'augmenter à l'avenir.

Mais il ne s'agit pas seulement du prix d'Aurora. Bien qu'Aurora résiste assez bien à la charge, beaucoup des clients de Hivekit utilisent la version sur site de l'application. Et là, ils doivent faire tourner leurs propres clusters de base de données qui sont facilement submergés par ce volume de mises à jour.

Pourquoi n'utilisons-nous pas une base de données spécialement conçue pour les données géospatiales ?

Malheureusement, cela n'existe pas. De nombreuses bases de données, de Mongo et H2 à Redis, prennent en charge les types de données spatiales comme les points et les zones. Il existe également des "bases de données spatiales", mais il s'agit exclusivement d'extensions qui se greffent sur les bases de données existantes. PostGIS, construit au-dessus de PostgreSQL est probablement le plus connu, mais il y en a d'autres comme Geomesa qui offrent d'excellentes capacités d'interrogation géospatiale au-dessus d'autres moteurs de stockage.

Malheureusement, ce n'est pas ce dont nous avons besoin.

Voici à quoi ressemble notre profil d'exigences :

• Performances d'écriture extrêmement élevées : nous voulons être en mesure de gérer jusqu'à 30 000 mises à jour de localisation par seconde et par nœud. Elles peuvent être mises en mémoire tampon avant d'être écrites, ce qui permet de réduire considérablement le nombre d'IOPS.
• Parallélisme illimité : plusieurs nœuds doivent être en mesure d'écrire des données simultanément, sans limite supérieure.
• Petite taille sur le disque : Compte tenu du volume de données, nous devons veiller à ce qu'elles occupent le moins d'espace possible sur le disque.
  

Cela signifie que nous devrons accepter certains compromis. Voici ce que nous acceptons :

[LIST][*] Des performances modérées pour les lectures sur disque : Notre serveur est construit autour d'une architecture en mémoire. Les requêtes et les filtres pour les flux en temps réel sont exécutés sur des données en mémoire et sont donc très rapides. Les lectures sur disque n'ont lieu que lorsqu'un...