Tidehunter : La base de données de nouvelle génération de Sui optimisée pour une faible latence et une amplification d'écriture réduite

En Bref

Sui a présenté Tidehunter, un moteur de stockage blockchain conçu spécifiquement pour remplacer RocksDB en réduisant l’amplification des écritures et en offrant un débit plus élevé, plus stable, ainsi qu’une latence plus faible pour les charges de travail des validateurs et des nœuds complets.

Sui, un réseau blockchain de couche 1, a introduit Tidehunter, un nouveau moteur de stockage conçu pour répondre aux exigences de performance, aux caractéristiques d’accès aux données et aux contraintes opérationnelles couramment rencontrées dans les infrastructures blockchain contemporaines.

Le système est positionné comme un successeur potentiel à la couche de base de données existante utilisée par les validateurs et les nœuds complets, reflétant un effort plus large pour moderniser l’infrastructure centrale en réponse à l’évolution de l’échelle et des profils de charge de travail des environnements blockchain de production.

Sui utilisait à l’origine RocksDB comme couche principale de stockage clé-valeur, une solution largement adoptée et mature qui permettait un développement rapide du protocole. À mesure que la plateforme s’est développée et que les exigences opérationnelles ont augmenté, les limitations fondamentales des bases de données LSM génériques sont devenues de plus en plus apparentes dans des environnements proches de la production.

Un tuning approfondi et une expertise interne approfondie ne pouvaient pas entièrement résoudre les inefficacités structurelles qui entraient en conflit avec les modèles d’accès typiques des systèmes blockchain. Cela a conduit à une évolution stratégique vers la conception d’un moteur de stockage optimisé spécifiquement pour les charges de travail blockchain, aboutissant au développement de Tidehunter.

Un facteur central derrière cette décision était l’amplification persistante des écritures. Des mesures effectuées dans des charges de travail réalistes de Sui ont montré des niveaux d’amplification d’environ dix à douze fois, ce qui signifie que de relativement petits volumes de données d’application généraient une quantité disproportionnée de trafic disque. Bien que ce comportement soit courant dans les systèmes basés sur LSM, il réduit la bande passante de stockage effective et intensifie la contention entre la compaction en arrière-plan et les opérations de lecture. Dans des environnements à forte intensité d’écriture ou équilibrés entre lecture et écriture, ce surcoût devient de plus en plus restrictif à mesure que le débit augmente.

Les tests de charge sur des clusters haute performance ont confirmé cet impact, avec une utilisation du disque approchant la saturation malgré des taux d’écriture modérés, soulignant le décalage croissant entre les architectures de stockage conventionnelles et les exigences de performance modernes des blockchains.

Architecture de Tidehunter : Un moteur de stockage optimisé pour les modèles d’accès blockchain et les charges de travail à haut débit soutenu

Le comportement de stockage dans Sui et des plateformes blockchain comparables est dominé par un petit ensemble de modèles d’accès aux données récurrents, et Tidehunter est conçu spécifiquement autour de ces caractéristiques. Une grande partie de l’état est adressée à l’aide de clés cryptographiques hachées, réparties uniformément et généralement associées à des enregistrements relativement volumineux, ce qui élimine la localité mais simplifie la cohérence et la précision.

En même temps, les blockchains s’appuient fortement sur des structures orientées vers l’ajout, telles que les journaux de consensus et les points de contrôle, où les données sont écrites dans l’ordre puis récupérées à l’aide d’identifiants croissants de manière monotone. Ces environnements sont également intrinsèquement axés sur l’écriture, tout en nécessitant un accès rapide sur des chemins de lecture sensibles à la latence, ce qui fait que l’amplification excessive des écritures constitue une menace directe pour le débit et la réactivité.

Au cœur de Tidehunter se trouve un pipeline d’écriture à haute concurrence conçu pour exploiter les capacités parallèles du stockage SSD moderne. Les écritures entrantes sont acheminées via un journal d’avance sans verrou capable de soutenir des taux d’opération extrêmement élevés, avec une contention limitée à une étape d’allocation minimale.

La copie des données se fait en parallèle, et le système évite les appels système par opération en utilisant des fichiers mappés en mémoire modifiables, tandis que la durabilité est gérée de manière asynchrone par des services en arrière-plan. Cette conception produit un chemin d’écriture prévisible et hautement parallèle qui peut saturer la bande passante disque sans être limité par la surcharge CPU.

Réduire l’amplification des écritures est considéré comme un objectif architectural principal plutôt qu’une étape d’optimisation. Au lieu d’utiliser le journal comme une zone de transit temporaire, Tidehunter stocke les données de façon permanente dans des segments de journal et construit des index qui référencent directement les décalages, éliminant ainsi les réécritures répétées des valeurs.

Les index sont fortement fragmentés pour maintenir une faible amplification des écritures et augmenter le parallélisme, supprimant ainsi le besoin de structures LSM traditionnelles. Pour les ensembles de données dominés par l’ajout, tels que les points de contrôle et les enregistrements de consensus, des stratégies de fragmentation spécialisées maintiennent les données récentes regroupées de manière étroite, de sorte que la surcharge d’écriture reste stable même lorsque les données historiques augmentent.

Pour les tables adressées par des clés hachées uniformément réparties, Tidehunter introduit un index de recherche uniforme optimisé pour un accès prévisible à faible latence. Plutôt que d’effectuer plusieurs petites lectures aléatoires, l’index lit une région contiguë légèrement plus grande qui contient statistiquement l’entrée souhaitée, permettant à la plupart des recherches de se terminer en un seul aller-retour disque.

Cette approche sacrifie délibérément une partie du débit de lecture pour une latence plus faible et plus stable, un compromis qui devient pratique car la réduction de l’amplification des écritures libère une bande passante disque substantielle pour le trafic de lecture. Le résultat est une performance plus cohérente sur des opérations sensibles à la latence telles que l’exécution de transactions et la validation d’état.

Pour mieux contrôler la latence en queue à grande échelle, Tidehunter combine I/O direct avec une mise en cache gérée par l’application. Les grandes lectures historiques évitent le cache de pages du système d’exploitation pour prévenir la pollution du cache, tandis que les données récentes et fréquemment consultées sont conservées dans des caches en espace utilisateur, informés par les modèles d’accès au niveau de l’application. En combinaison avec sa disposition d’indexation, cela réduit les aller-retours disque inutiles et améliore la prévisibilité sous charge soutenue.

La gestion du cycle de vie des données est également simplifiée. Étant donné que les enregistrements sont stockés directement dans des segments de journal, la suppression des données historiques obsolètes peut être effectuée en supprimant des fichiers de journal entiers une fois qu’ils sortent de la fenêtre de rétention. Cela évite les mécanismes complexes et gourmands en I/O de compaction requis par les bases de données LSM et permet un élagage plus rapide et plus prévisible même lorsque les ensembles de données s’étendent.

Sur l’ensemble des charges de travail conçues pour refléter l’utilisation réelle de Sui, Tidehunter démontre un débit supérieur et une latence inférieure à ceux de RocksDB tout en consommant beaucoup moins de bande passante d’écriture disque. La amélioration la plus visible provient de la quasi-élimination de l’amplification des écritures, ce qui permet à l’activité disque de mieux correspondre aux écritures au niveau de l’application et de préserver la capacité d’I/O pour la lecture. Ces effets sont observés à la fois dans des benchmarks contrôlés et dans des déploiements complets de validateurs, indiquant que les gains dépassent le simple test synthétique.

L’évaluation est réalisée à l’aide d’un cadre de référence indépendant de la base de données qui modélise des mélanges réalistes d’inserts, de suppressions, de recherches ponctuelles et de charges de travail d’itération. Les tests sont paramétrés pour refléter des distributions de clés similaires à celles de Sui, des tailles de valeurs, et des ratios lecture-écriture, et sont exécutés sur du matériel conforme aux spécifications recommandées pour les validateurs. Dans ces conditions, Tidehunter maintient systématiquement un débit supérieur et une latence inférieure à ceux de RocksDB, avec les avantages les plus importants dans les scénarios à forte écriture et équilibrés.

Les benchmarks au niveau du validateur confirment également ces résultats. Lorsqu’il est intégré directement dans Sui et soumis à une charge transactionnelle soutenue, les systèmes utilisant Tidehunter maintiennent un débit stable et une latence plus faible à des points de fonctionnement où les déploiements basés sur RocksDB commencent à souffrir d’une augmentation de l’utilisation du disque et d’une dégradation des performances. Les mesures montrent une pression disque réduite, une utilisation CPU plus stable et une latence de finalité améliorée, soulignant une divergence claire dans le comportement sous charge comparable.

Tidehunter représente une réponse pratique aux exigences opérationnelles des systèmes blockchain à haute performance et à long terme. À mesure que les blockchains évoluent vers des charges de travail soutenues plutôt que par rafales, l’efficacité du stockage devient une exigence fondamentale pour la performance du protocole. La conception de Tidehunter reflète un virage vers une infrastructure construite explicitement pour cette prochaine étape de l’échelle, avec des détails techniques supplémentaires et des plans de déploiement à suivre.