Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration

Le papier présente Nezha, un système de stockage distribué qui intègre la séparation clé-valeur avec le protocole Raft pour éliminer les surcharges d'E/S liées aux opérations de persistance redondantes et ainsi améliorer considérablement le débit tout en garantissant une forte cohérence.

L'essentiel

Voici une explication simple et imagée du papier de recherche sur Nezha, conçue pour être comprise par tous, même sans être expert en informatique.

🌋 Nezha : Le Super-Héros de la Gestion des Données

Imaginez que vous gérez une immense bibliothèque (un stockage de données distribué) où des milliers de livres (vos données) sont stockés sur plusieurs étagères dans différents bâtiments (des serveurs). Pour que tout le monde soit d'accord sur quel livre est où, même si un bâtiment brûle ou s'effondre, vous avez besoin d'un chef très organisé qui note tout dans un journal de bord. C'est ce qu'on appelle le protocole Raft.

Le problème, c'est que dans les systèmes actuels, ce processus est très lent et gaspille beaucoup d'énergie (de la puissance de calcul et du temps d'écriture sur le disque dur).

Voici comment Nezha résout ce problème avec trois idées géniales.

---

1. Le Problème : La "Double (ou Triple) Facture" 📝💸

Dans un système classique (comme un système de stockage actuel), quand vous voulez écrire une information (disons, "Le livre A est sur l'étagère 3"), le système doit faire trois choses lourdes et inutiles :

1. Le Chef écrit dans son journal (le journal Raft) pour dire "J'ai reçu la demande".
2. Le Chef écrit encore dans un brouillon (le journal de sécurité du système de stockage) pour dire "Je suis sûr de ce que j'écris".
3. Le Chef écrit enfin le livre dans la bibliothèque (le fichier de données final).

C'est comme si vous deviez envoyer un email, puis le recopier à la main sur un cahier, puis le dactylographier à nouveau sur un ordinateur, juste pour dire "Bonjour". C'est lent et ça use vos stylos (vos disques durs).

2. La Solution de Nezha : La Séparation "Clé / Valeur" 🗝️📦

Nezha utilise une astuce appelée séparation Clé-Valeur.

Imaginez que vos données sont composées de deux parties :

• La Clé (Key) : C'est le titre du livre ou son code-barres (très petit, facile à lire).
• La Valeur (Value) : C'est le contenu du livre, les pages entières (très gros, lourd à déplacer).

L'innovation de Nezha :
Au lieu de copier le gros livre trois fois, Nezha dit :

"Hé, le Chef (Raft), tu n'as besoin de noter que le code-barres et une adresse dans ton journal. Le gros livre, on le stocke directement dans un grand entrepôt spécial (ValueLog) une seule fois, et on note juste où il se trouve."

L'analogie du restaurant :

• Système classique : Le serveur écrit la commande sur un ticket, la recopie sur un bloc-notes, puis l'écrit sur l'ordinateur de la cuisine, et enfin l'écrit sur l'assiette.
• Système Nezha : Le serveur note seulement "Table 4, Plat 12" sur le ticket. Le plat (le gros objet) est déjà en cuisine. Le serveur envoie juste le ticket. Fini le gaspillage !

Résultat : Les écritures sont 4,6 fois plus rapides !

---

3. Le Défi : Comment retrouver les livres ? (Le problème de la lecture) 📖🔍

Il y a un petit hic. Si on ne stocke que les adresses, quand quelqu'un veut lire un livre, il faut d'abord chercher l'adresse, puis aller chercher le livre. C'est comme chercher une aiguille dans une botte de foin si les livres sont éparpillés au hasard. Cela peut rendre la lecture lente.

Nezha a une solution intelligente : Le Garbage Collector (GC) "Conscient de Raft".

Imaginez que votre bibliothèque est un peu en désordre. Nezha a un robot de nettoyage qui travaille en arrière-plan :

1. Il ne gâche rien : Il sait exactement quand le Chef (Raft) est occupé, donc il ne touche pas aux livres en cours de tri.
2. Il range tout : Il prend les livres éparpillés et les remet dans l'ordre alphabétique sur des étagères spéciales.
3. Il crée un index : Il fait un catalogue ultra-rapide.

Grâce à ce robot, quand vous demandez un livre, le système sait exactement où il est, même si les données ont été triées.

L'analogie du tri postal :

• Sans Nezha : Le facteur doit courir dans tout le quartier pour trouver chaque lettre, car elles sont jetées au sol au fur et à mesure qu'elles arrivent.
• Avec Nezha : Le robot de nettoyage (GC) range les lettres dans des boîtes triées par nom de rue. Le facteur n'a qu'à ouvrir la bonne boîte.

Résultat : Les lectures sont 12 % plus rapides, et les recherches de listes (scans) sont 72 % plus rapides !

---

4. La Sécurité : Comment ne rien perdre ? 🛡️

Vous vous demandez peut-être : "Si le robot nettoie et range, est-ce qu'il ne jette pas quelque chose d'important ?"

Nezha utilise un système à trois phases pour être sûr à 100 % :

1. Phase 1 (Avant le nettoyage) : Tout est stocké normalement.
2. Phase 2 (Pendant le nettoyage) : Le robot travaille sur les vieux dossiers pendant que les nouveaux clients sont dirigés vers une nouvelle zone de stockage. Personne n'est bloqué.
3. Phase 3 (Après le nettoyage) : Une fois le tri fini, on jette les vieux désordres et on utilise le nouveau rangement parfait.

C'est comme rénover une maison pendant que les habitants y vivent : on construit une nouvelle aile, on y emménage les gens, puis on démolit l'ancienne aile. Zéro interruption de service.

---

En Résumé : Pourquoi c'est génial ? 🚀

Le papier de recherche montre que Nezha est un système de stockage révolutionnaire parce qu'il :

• Élimine le gaspillage : Il écrit les données lourdes une seule fois au lieu de trois.
• Garde la sécurité : Il respecte les règles strictes du protocole Raft (si un serveur tombe, les données sont sauvées).
• Rend tout plus rapide : Que vous écriviez, lisiez ou cherchiez des listes de données, Nezha est beaucoup plus performant que les systèmes actuels (comme TiKV ou etcd).

En une phrase : Nezha est comme un chef d'orchestre qui a appris à ne pas écrire la même partition trois fois, tout en s'assurant que chaque musicien joue juste, même si un instrument casse en plein concert. 🎻✨

Résumé technique

Voici un résumé technique détaillé de l'article "Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration" en français.

1. Problématique

Les systèmes de stockage distribué de type clé-valeur (KV), souvent basés sur des arbres LSM (Log-Structured Merge-trees) comme RocksDB, sont essentiels pour les applications de données massives. Cependant, lorsqu'ils sont combinés avec des protocoles de consensus comme Raft pour garantir la cohérence forte, ils souffrent d'un problème critique de redondance des opérations de persistance (I/O).

Dans une architecture traditionnelle (Raft + LSM-tree), chaque opération d'écriture subit au moins trois écritures disque distinctes :

1. Persistance du journal Raft (Raft Log) : Pour garantir la cohérence et la récupération après panne.
2. Journal d'écriture anticipé (WAL) du moteur de stockage : Pour la durabilité des données avant l'écriture en mémoire.
3. Persistance du MemTable vers les fichiers SSTable : Lors du processus de compaction de l'arbre LSM.

Cette surcharge d'écriture (write amplification) crée un goulot d'étranglement majeur, surtout avec l'avènement de disques SSD NVMe très rapides où les inefficacités logicielles deviennent le facteur limitant. De plus, les mécanismes de Garbage Collection (GC) classiques dans les systèmes à séparation clé-valeur peuvent compromettre l'intégrité des journaux Raft ou dégrader les performances de lecture.

2. Méthodologie : L'Architecture Nezha

L'équipe propose Nezha, un système de stockage distribué qui intègre de manière innovante la séparation clé-valeur directement au sein du protocole Raft, tout en gérant les défis de cohérence et de lecture.

A. KVS-Raft (Consensus Optimisé)

Au lieu de stocker les valeurs complètes dans le journal Raft et de les réécrire dans le moteur de stockage, Nezha utilise une stratégie de séparation :

• Stockage unique : Les valeurs sont persistées une seule fois dans un fichier journal append-only (ValueLog) géré par le consensus.
• État machine léger : Le moteur de stockage (basé sur RocksDB) ne stocke que des pointeurs (offsets) vers les valeurs dans le ValueLog, et non les valeurs elles-mêmes.
• Réduction des I/O : Cela réduit le nombre d'écritures disque pour une valeur de 3 à 1, éliminant la redondance entre la couche consensus et la couche stockage.

B. Cadre de Garbage Collection (GC) "Raft-Aware"

La séparation clé-valeur pose un défi pour la lecture (les valeurs sont dispersées dans le ValueLog) et pour la cohérence des journaux Raft (qui doivent rester ordonnés). Nezha résout cela via un cadre GC adaptatif divisé en trois phases :

1. Pré-GC : Le système écrit dans un stockage actif (Active Storage).
2. Pendant-GC : Un nouveau module de stockage (New Storage) est créé pour gérer les nouvelles requêtes. Le système effectue une compaction asynchrone des données de l'ancien stockage, réorganisant les entrées par ordre de clé dans un fichier ValueLog trié.
3. Post-GC : Une fois la compaction terminée, les anciennes données sont supprimées et le nouveau stockage devient le stockage actif.

Ce mécanisme utilise des index de hachage pour accélérer les recherches ponctuelles (Get) et l'organisation séquentielle des données triées pour optimiser les plages de lecture (Scan).

C. Mécanisme de Traitement des Requêtes en Trois Phases

Pour garantir la cohérence pendant les transitions de GC, Nezha implémente une logique de lecture spécifique :

• Écriture (Put) : Toujours dirigée vers le module de stockage actuel, indépendamment de l'état du GC.
• Lecture (Get/Scan) : Le système interroge parallèlement les modules de stockage actifs et en cours de compaction (ou triés), en priorisant les données les plus récentes (celles du nouveau stockage) pour assurer la cohérence forte sans bloquer le système.

3. Contributions Clés

1. Identification du goulot d'étranglement : Mise en évidence que les opérations de persistance redondantes entre Raft et les moteurs LSM sont un frein majeur aux performances sur le matériel moderne.
2. Conception de KVS-Raft : Un protocole de consensus qui intègre nativement la séparation clé-valeur, réduisant l'amplification d'écriture tout en préservant les propriétés de sécurité de Raft.
3. Framework GC Raft-Aware : Une solution qui réorganise les données dispersées en fichiers triés pour optimiser les lectures, tout en gérant la transition sans interruption de service.
4. Mécanisme de traitement triphasé : Une approche robuste pour gérer la cohérence des requêtes pendant les cycles de nettoyage et de réorganisation des données.

4. Résultats Expérimentaux

Les évaluations ont été menées sur un cluster de 3 nœuds avec des charges de travail variées (YCSB) et des tailles de valeurs allant de 1 Ko à 256 Ko. Nezha a été comparé à des systèmes de référence comme Original (Raft + RocksDB), TiKV, PASV, Dwisckey et LSM-Raft.

Améliorations de débit moyen :

• Opérations d'écriture (Put) : +460,2 % par rapport au système de référence. La performance s'améliore encore avec des valeurs plus grandes grâce à la réduction drastique des écritures disque.
• Opérations de lecture ponctuelle (Get) : +12,5 %. Contrairement aux systèmes de séparation classiques qui ralentissent les lectures, le GC de Nezha compense le coût de recherche d'offset grâce à l'indexation.
• Opérations de balayage (Scan) : +72,6 %. L'organisation séquentielle des données triées après GC transforme les I/O aléatoires en I/O séquentiels, offrant un gain significatif.

Autres observations :

• Latence : Réduction de 59,2 % pour les écritures et de 10,3 % pour les lectures ponctuelles.
• Évolutivité : Nezha maintient une meilleure scalabilité que les systèmes traditionnels lors de l'augmentation de la taille du cluster (de 3 à 7 nœuds).
• Temps de récupération : Réduction de ~34 % du temps de récupération après une panne, grâce à la réduction du volume de données à restaurer dans RocksDB (seuls les offsets sont stockés).

5. Signification et Impact

Le travail de Nezha représente une avancée significative dans le domaine du co-design consensus-stockage.

• Efficacité I/O : Il démontre que la redondance inhérente aux architectures traditionnelles (Raft + LSM) peut être éliminée sans sacrifier la cohérence forte.
• Équilibre Lecture/Écriture : Contrairement à la séparation clé-valeur classique (comme WiscKey) qui améliore les écritures mais dégrade les lectures, Nezha résout ce compromis grâce à son mécanisme de GC intelligent.
• Réduction des coûts : En réduisant les écritures disque, le système diminue l'usure des SSD et les coûts de stockage dans les environnements cloud basés sur la consommation.

En résumé, Nezha offre une nouvelle architecture de référence pour les bases de données distribuées à forte cohérence, capable de tirer pleinement parti des performances des disques NVMe modernes tout en garantissant la fiabilité des données.