Qu’est-ce que RocksDB ? Le magasin clé-valeur embarqué

Qu’est-ce que RocksDB ?

RocksDB est un magasin clé-valeur persistant et embarquable, optimisé pour un stockage rapide. Il accepte des clés et des valeurs sous forme de tableaux d’octets arbitraires, les maintient triées et les stocke durablement sur disque. 

Le point le plus important à comprendre dès le départ est que RocksDB est une bibliothèque, et non un serveur. Il n’y a aucun processus auquel se connecter, aucun port à ouvrir et aucun langage de requête à apprendre.

RocksDB s’intègre à une application et s’exécute au sein de son processus, en lisant et en écrivant des fichiers sur le disque local. C’est ce qui rend RocksDB rapide : il n’y a aucun transit réseau entre le code de l’application et les données qu’il traite. RocksDB reste minimaliste, car il laisse délibérément la réplication, le partitionnement et les requêtes aux systèmes construits par-dessus.

En bref, RocksDB est un moteur de stockage, c’est-à-dire le composant autour duquel sont construites des bases de données comme TiDB et YugabyteDB.

RocksDB est-il identique à LevelDB ?

Non, mais ils proviennent de la même base de code. RocksDB a vu le jour en 2012 sous forme de fork de LevelDB, le magasin clé-valeur léger écrit par Jeff Dean et Sanjay Ghemawat chez Google. 

LevelDB a été conçu pour des environnements modestes, comme le backend IndexedDB d’un navigateur ou un appareil embarqué unique. Plusieurs choix de conception en découlaient, notamment une compaction monothread, une utilisation prudente de la mémoire et peu de possibilités de réglage.

Les ingénieurs de Facebook, aujourd’hui Meta, ont repris cette base et l’ont reconstruite pour les charges de travail serveur. Leur objectif était de saturer le matériel moderne tout en gérant, sous une pression d’écriture continue, des jeux de données bien plus volumineux que la mémoire. 

RocksDB est devenu open source en 2013 et s’est considérablement éloigné de LevelDB. Il propose désormais la compaction multithread, les familles de colonnes, les transactions, les sauvegardes, les opérateurs de fusion, des styles de compaction configurables et une liste notoirement longue d’options de réglage.

LevelDB et RocksDB ont un air de famille, mais il n’est plus raisonnable de les considérer comme interchangeables depuis une dizaine d’années.

Comment fonctionne RocksDB ?

RocksDB repose sur un arbre de fusion structuré en journal (arbre LSM), une structure de données qui sacrifie la simplicité de lecture au profit du débit d’écriture. 

En pratique, les écritures entrantes sont placées dans une mémoire tampon appelée memtable. Elles sont simultanément ajoutées à un journal d’écriture anticipée sur disque afin de garantir leur durabilité. 

Lorsque la memtable est pleine, elle est figée puis transférée sur disque sous la forme d’un fichier immuable et trié appelé Sorted String Table (SST). Les fichiers SST s’accumulent dans une hiérarchie de niveaux, tandis qu’un processus en arrière-plan appelé compaction les fusionne continuellement. Il élimine les valeurs écrasées et les clés supprimées afin de conserver une structure propre, triée et durable.

Les lectures consultent d’abord la memtable, puis parcourent les différents niveaux de fichiers SST. Les filtres de Bloom permettent à RocksDB d’ignorer les fichiers qui ne peuvent pas contenir la clé, tandis qu’un cache de blocs conserve les données fréquemment utilisées en mémoire. La plupart des lectures n’accèdent donc jamais à plus d’un ou deux fichiers.

Quelle est la différence entre les arbres LSM et les arbres B ?

Les arbres B, utilisés par la plupart des bases de données traditionnelles, mettent les données à jour sur place. Les écritures aléatoires sont donc dispersées sur le disque. Les arbres LSM regroupent les écritures et les ajoutent séquentiellement, ce qui produit de grandes écritures séquentielles, idéales pour les SSD et les charges à fort volume d’ingestion. En contrepartie, la valeur actuelle d’une clé peut être répartie entre plusieurs fichiers. La compaction, les filtres de Bloom et la mise en cache sont alors nécessaires pour limiter ce compromis. 

Chaque décision de conception d’un arbre LSM cherche en définitive un équilibre entre trois contraintes :

• Amplification des écritures
• Amplification des lectures
• Amplification de l’espace

Améliorer deux de ces aspects tend à dégrader le troisième. 

Ce triangle est le modèle mental le plus important pour comprendre le réglage de RocksDB. 

À quoi sert RocksDB ?

RocksDB est utilisé lorsqu’une application a besoin d’un stockage clé-valeur rapide, durable et ordonné sur un disque local, sans la surcharge liée à l’exécution d’un serveur de base de données distinct. Des exemples concrets illustrent mieux ce modèle que des catégories.

Kafka Streams conserve l’état de chaque tâche de traitement — agrégations en cours, jointures et calculs fenêtrés — dans un magasin RocksDB local. L’état peut ainsi dépasser la capacité de la mémoire et survivre aux redémarrages sans ajouter un aller-retour réseau à chaque recherche.

ZippyDB de Meta entoure RocksDB d’une couche de réplication, d’une gestion des partitions et de services de configuration afin de proposer un magasin clé-valeur distribué entièrement géré. La répartition des rôles est claire : RocksDB fournit le stockage, et tout ce qui relève du serveur est construit autour.

La couche de stockage de TiDB exécute RocksDB sur chaque nœud comme moteur sous-jacent d’une base de données SQL distribuée. Elle encode la structure des tables dans les préfixes de clés, afin que le balayage d’une table devienne une lecture contiguë unique de clés triées.

Chaque validateur Solana basé sur Agave écrit le registre dans RocksDB, avec des clés définies par slot afin que les données consécutives du registre soient adjacentes sur le disque.

Les deux derniers exemples sont intéressants, car les clés sont stockées dans l’ordre — octet par octet par défaut, ou selon un comparateur personnalisé — ce qui rend efficaces les balayages de plages et les recherches par préfixe.

Dans les systèmes reposant sur RocksDB, une part étonnamment importante de la conception des schémas consiste à exploiter cet ordre.

Qui utilise RocksDB ?

Au-delà des systèmes ci-dessus, RocksDB constitue la base de tout système ayant besoin d’un moteur de stockage embarqué, éprouvé et optimisé pour les écritures. Les équipes le choisissent pour bénéficier de dix ans de durcissement en production chez Meta plutôt que d’en développer un de zéro.

Parmi les cas notables :

• Kafka Streams l’utilise comme moteur par défaut pour les magasins d’état
• Apache Flink propose également un backend d’état RocksDB pour les états enregistrés par points de contrôle qui sont trop volumineux pour tenir en mémoire
• MyRocks l’intègre comme moteur de stockage MySQL. Il a été développé chez Meta pour réduire l’espace de stockage de certains des plus grands parcs MySQL au monde
• La couche de stockage de TiDB, TiKV, utilise RocksDB avec des instances distinctes pour les journaux Raft et les données clé-valeur
• Le magasin de documents de YugabyteDB, DocDB, utilise RocksDB
• BlueStore de Ceph utilise RocksDB pour les métadonnées de stockage d’objets
• ArangoDB fournit RocksDB comme moteur de stockage par défaut depuis la version 3.4, et comme moteur unique depuis la version 3.7

RocksDB est principalement utilisé pour les charges de travail intensives en écriture, plus volumineuses que la mémoire et exécutées sur des SSD. Nous reviendrons sur ce point plus loin dans cet article.

Comment Solana utilise-t-il RocksDB ?

Solana est une blockchain hautes performances et à faible latence fondée sur la preuve d’enjeu, réputée pour l’importance qu’elle accorde à la vitesse, à l’efficacité et aux applications grand public. Le registre de Solana réside dans RocksDB. Le client validateur Agave stocke le registre dans le Blockstore, un composant qui contient une base de données RocksDB divisée en espaces de clés indépendants et configurables. 

Des familles de colonnes distinctes contiennent les données de shreds et le codage d’effacement des shreds, c’est-à-dire les unités brutes des données du registre à leur arrivée sur le réseau, ainsi que les statuts des transactions, les index associant les adresses aux signatures et diverses métadonnées.

Le profil d’écriture d’un validateur est extrême par rapport à la plupart des charges de travail de bases de données. Un validateur doit ingérer en continu des shreds, indexés par des numéros de slot qui augmentent de façon presque monotone, au débit maximal du réseau, et ce indéfiniment. Une archive non élaguée du registre dépasse largement plusieurs centaines de téraoctets et augmente au minimum de plusieurs dizaines de téraoctets par an.

Avec la compaction par niveaux, les familles de colonnes de shreds généraient suffisamment de tâches de compaction en arrière-plan pour que les validateurs commencent à subir des interruptions d’écriture, le mécanisme intégré de RocksDB qui ralentit l’ingestion lorsque la compaction prend du retard. 

Vers 2021, les familles de colonnes de shreds sont passées à la compaction FIFO, un style minimaliste qui supprime simplement le fichier le plus ancien lorsque la limite de taille est atteinte. La méthode FIFO est généralement dangereuse pour les charges de travail courantes. Toutefois, comme les clés des shreds arrivent dans un ordre de slots presque monotone, les validateurs pouvaient supprimer le fichier le plus ancien, puisqu’il contenait les slots les plus anciens. Le style de compaction correspondait ainsi presque parfaitement au profil de la charge de travail.

Des optimisations ultérieures de la compaction par niveaux ont suffisamment réduit son amplification des E/S pour que FIFO ne présente plus aucun avantage. Le chemin FIFO a donc été rendu obsolète en juin 2024, puis supprimé en novembre de la même année.

Firedancer, le client validateur Solana de Jump Crypto écrit en C, abandonne entièrement RocksDB au profit d’une couche de stockage interne conçue sur mesure.

Déterminer si un moteur de stockage développé de zéro peut surpasser dix ans de durcissement et de réglage de RocksDB reste une question ouverte intéressante dans l’ingénierie des validateurs.

Quand RocksDB n’est-il pas le bon outil ?

RocksDB n’est pas le bon outil plus souvent que son omniprésence ne le laisse penser. Les possibilités de réglage sont immenses, avec des centaines d’options dont les interactions sont loin d’être évidentes. Un mauvais réglage est donc la norme plutôt que l’exception. 

Pire encore, les paramètres par défaut de RocksDB sont raisonnables, mais pas optimaux. Les développeurs doivent donc comprendre les compromis d’amplification présentés ci-dessus pour obtenir de réels gains de performances. Une ingestion intensive et prolongée peut dépasser la capacité de la compaction en arrière-plan et provoquer des interruptions d’écriture, qui surviennent généralement lorsque le système est le plus sollicité.

De plus, RocksDB est une bibliothèque, et non un serveur. Tout ce qu’un serveur de base de données classique fournirait — réplication, partitionnement, sauvegardes, contrôle d’accès, couche de requête et outils d’exploitation — doit être développé.

Le profil de la charge de travail joue également un rôle considérable. 

RocksDB est un moteur orienté lignes, conçu pour les recherches ponctuelles et les balayages de plages. Les charges de travail analytiques qui parcourent de vastes ensembles de données et effectuent des agrégations entre colonnes sont mieux prises en charge par un magasin colonnaire comme ClickHouse.

Rien de tout cela ne justifie d’éviter RocksDB. Cela montre plutôt qu’il faut le choisir délibérément. Chez Helius, nous avons directement évalué ces risques lors de la refonte de notre couche d’archivage et avons tout de même choisi RocksDB, car notre charge de travail correspondait précisément au profil pour lequel RocksDB a été conçu : des recherches ponctuelles et des balayages de plages restreintes sur un vaste jeu de données alimenté principalement par ajout. 

Conclusion

RocksDB est un magasin clé-valeur embarquable, persistant et trié qui sacrifie certaines commodités opérationnelles au profit de performances brutes sur le disque local. Issu de LevelDB, il a été renforcé chez Meta pour les SSD et les machines multicœurs. Il est désormais intégré à de nombreux systèmes dans le monde, des processeurs de flux et bases de données SQL distribuées aux clusters de stockage et au registre de Solana.

Si travailler sur des déploiements RocksDB hautes performances à grande échelle vous passionne, venez les construire avec nous.

Solana avance à toute vitesse pour devenir la couche de règlement de la finance mondiale, et son infrastructure repose précisément sur les mécanismes décrits dans cette série. Résolvez des problèmes systèmes complexes sur certains des meilleurs équipements disponibles, à l’échelle planétaire.

Nous recrutons dans toute notre équipe d’ingénierie. Découvrez tous nos postes à pourvoir sur helius.dev/careers.