Face à la croissance du volume des données à ingérer et stocker, Datadog a fini par atteindre les limites de sa base de données chronologique principale, un système interne chargé de stocker les données métriques brutes et de les fournir en temps réel selon les requêtes des clients. Et il y en a beaucoup : chaque minute, le fournisseur en observabilité cloud collecte plusieurs milliards d'événements de ses millions d'instances, avec un volume de données multiplié par 30 rien qu’entre 2017 et 2022. Pour y remédier, le spécialiste en observabilité cloud a lancé Monocle (annoncé début août), dernière génération de sa technologie de moteur de stockage de séries chronologiques en temps réel. Ecrit en Rust, ce dernier doit améliorer le débit d’ingestion des données tout en réduisant la latence des requêtes. Il s’agit de la 6e génération de système de stockage de données de l’éditeur après Cassandra, Redis ou encore RocksDB. Grâce à lui, Datadog annonce avoir réussi à multiplier par 60 les performances d'ingestion et par 5 la vitesse des requêtes.

Monocle se base sur deux services : une base de données de séries chronologiques en temps réel (RTDB) qui stocke les données métriques brutes sous forme de tuples <timeseries_id, timestamp, value>, agrège et fournit les données métriques les plus récentes. Et une autre d'index qui gère les identifiants métriques et leurs balises, en les stockant sous forme de tuples <timeseries_id, tags>. « En amont, le routeur de stockage distribue les métriques entrantes entre les nœuds RTDB en fonction de la charge. En aval, le service de requête de métriques utilise les informations du routeur pour se connecter aux nœuds RTDB et aux nœuds d'indexation appropriés, récupérer les résultats de chacun et les combiner », explique Datadog. 

Une conception efficace de fragment par coeur

L’un des principaux atouts de Monocle réside dans sa conception de fragment par coeur (shard per core) pour améliorer sa vitesse en utilisant un partitionnement à plusieurs niveaux qui répartit les données et la charge de travail jusqu'au niveau de chaque coeur processeur associé à un thread dédié. Ce moteur de stockage de séries chronologiques de type LSM (log-structured merge-tree) s’avère particulièrement adapté aux charges de travail de forte intensité d'écriture en les mettant en mémoire tampon et en vidant périodiquement les fichiers triés sur le disque. 

« Dans un LSM classique, y compris RocksDB, les écritures entrantes sont enregistrées dans une table mémoire, un tampon en mémoire. La première est généralement une structure ordonnée qui prend en charge les nouvelles écritures et lectures. Lorsque elle est pleine ou arrive à expiration, elle devient accessible en lecture seule et est vidée de manière asynchrone sur le disque. Une fois la vidange terminée, la mémoire de cette memtable est récupérée et les récentes écritures sont enregistrées dans une autre table mémoire », explique Datadog. « Dans notre système, nous avons simplifié le chemin d'écriture en évitant complètement les conflits entre threads. Chaque thread de travail gère sa propre table de mémoire privée, aucun autre thread n'y écrit ».