Développement de rqlite 9.0 : réduire de moitié l’utilisation du disque

• rqlite est une base de données relationnelle distribuée légère et open source écrite en Go
• Elle est construite sur le protocole de consensus Raft et utilise SQLite comme moteur de stockage
• Le développement de la version 9.0 a commencé, avec pour objectif de réduire l’utilisation du disque d’environ 50 %
• Cet objectif sera atteint grâce à une refonte de haut niveau de l’architecture, qui éliminera la principale cause de consommation disque de rqlite

Qu’est-ce qui occupe actuellement l’essentiel de l’espace disque ?

• Journal Raft :
  • Journal des modifications apportées au système
  • Ce journal est au cœur du système de consensus Raft
• Base de données SQLite active :
  • Base de données live que rqlite utilise pour fournir la lecture et l’écriture
  • Une fois qu’une instruction SQLite est validée avec succès dans le journal Raft, elle est appliquée à la base de données SQLite active
• Snapshot de la base de données SQLite active :
  • Pour éviter que le journal Raft ne croisse sans limite, le sous-système Raft de rqlite crée et stocke périodiquement une copie ponctuelle de la base de données SQLite active
  • Cette copie est appelée un snapshot
  • Une fois le snapshot créé, rqlite peut tronquer le journal Raft
  • Cette copie snapshotée est utilisée par rqlite pour restaurer un nœud lors d’un redémarrage, ou envoyée à un autre nœud lorsque celui-ci doit « rattraper » l’état du cluster rqlite existant
  • La création de snapshots et la troncature du journal sont des concepts fondamentaux des systèmes basés sur Raft

Architecture de haut niveau pour rqlite 9.0

• La stratégie principale pour réduire l’utilisation du disque consiste à supprimer la nécessité de stocker, dans le système Raft, une copie snapshotée de la base de données SQLite active
• Le journal Raft est périodiquement tronqué grâce à la création de snapshots et cesse de croître au-delà d’un certain point, mais la base de données SQLite active continue de grossir à mesure que davantage de données y sont écrites
• Et comme la copie snapshotée de la base SQLite a pratiquement la même taille que la base de données SQLite active, sa taille augmente elle aussi
• Par conséquent, si cette copie snapshotée peut être supprimée, rqlite utilisera 50 % d’espace disque en moins
• Cependant, un nœud rqlite a besoin d’une copie snapshotée à certains moments. Cela est inévitable.
• Alors comment se passer de cette copie tout en répondant au besoin de création et de restauration de snapshots ?
• Pour comprendre comment éviter de stocker une copie supplémentaire pendant le processus de snapshot, il est important de savoir que rqlite exécute la base de données SQLite sous-jacente en mode Write-Ahead Log (WAL)
• Dans l’architecture proposée pour la 9.0, le fichier de base de données SQLite active (hors fichier WAL associé) et la copie snapshotée du système Raft sont logiquement identiques
• En exploitant ce fait, il devient possible d’éliminer la nécessité de stocker une copie snapshotée séparée dans le système Raft

Nouvelle approche de création de snapshots

• Création de snapshots et checkpointing WAL :
  • Au moment de créer un snapshot, rqlite effectue un checkpoint du Write-Ahead Log (WAL) de la base de données SQLite active
  • Toutes les écritures ultérieures sont ensuite envoyées vers un nouveau fichier WAL, ce qui permet au fichier SQLite principal de rester inchangé à partir du moment où le snapshot a été créé
  • En conséquence, jusqu’au snapshot suivant, le fichier SQLite principal représente l’état ponctuel nécessaire au stockage des snapshots Raft
  • Cette approche permet d’utiliser le fichier SQLite combiné au fichier WAL pour les opérations normales de lecture et d’écriture, tandis que le fichier SQLite principal inchangé sert d’ensemble de données pour le stockage des snapshots Raft
  • Aucune copie supplémentaire n’est désormais nécessaire !
• Écriture d’une référence dans le stockage de snapshots :
  • Au lieu de copier l’intégralité du fichier SQLite, rqlite écrit une référence, par exemple un checksum, dans le stockage de snapshots
  • Cette référence peut être utilisée pour vérifier, chaque fois que les données du snapshot sont nécessaires, que le fichier SQLite principal correspond bien à ce que le stockage de snapshots référence
    • (Cette vérification protège contre les bugs, les erreurs d’exploitation ou la corruption disque, mais n’est pas strictement nécessaire)
• Restauration à partir d’un snapshot :
  • Comme indiqué plus haut, toutes les écritures après le processus de snapshot sont envoyées vers le fichier WAL ; le fichier SQLite principal reste donc prêt à être utilisé pour le processus de restauration à partir du snapshot, par exemple lors du redémarrage d’un nœud ou lors de l’envoi du snapshot à un autre nœud
  • Autrement dit, le fichier SQLite principal (en ignorant le fichier WAL associé) reste logiquement identique à ce qui aurait été écrit dans le stockage de snapshots Raft si rqlite avait effectivement créé une copie redondante
• Cette nouvelle architecture est appelée « snapshots de référence »

Améliorations bonus

• Les snapshots de référence apporteront aussi plusieurs autres améliorations importantes
• Création de snapshots plus rapide : comme très peu de données sont écrites dans le stockage de snapshots Raft, le processus de snapshot sera beaucoup plus rapide
  • Il se résumera au temps de checkpoint du WAL SQLite (généralement très court) et au temps de calcul du checksum
  • Il ne sera plus nécessaire de copier de gros volumes de données SQLite vers le stockage de snapshots à chaque création de snapshot
  • L’avantage de snapshots plus rapides est évident quand on sait que les écritures vers rqlite sont bloquées pendant le processus de snapshot
• Redémarrage plus rapide : même les nœuds contenant plusieurs gigaoctets de données SQLite redémarreront beaucoup plus vite
  • Aujourd’hui, au redémarrage, rqlite doit restaurer le fichier de base de données SQLite active à partir de la copie présente dans le stockage de snapshots Raft
  • Mais avec cette nouvelle architecture, le fichier de base de données SQLite active sera déjà au bon emplacement au démarrage
  • Au mieux, rqlite n’aura qu’à comparer le checksum du stockage de snapshots avec celui de la base de données SQLite active
  • Les systèmes de plusieurs Go devraient pouvoir redémarrer en quelques secondes

Étapes suivantes

• La transition vers rqlite 9.0 constituera une étape importante dans l’optimisation de l’efficacité de rqlite
• En mettant en œuvre les snapshots de référence, le projet s’attend à réduire fortement l’utilisation du disque, à accélérer la création des snapshots et à améliorer le temps de redémarrage des nœuds
• De nombreux détails doivent encore être traités correctement, notamment la gestion du WAL SQLite, les mises à niveau fluides depuis les versions précédentes et le choix du checksum
• Il faut donc rester attentif aux prochaines mises à jour à mesure que cette version majeure avance

[xguru]

rqlite - une base de données distribuée légère basée sur SQLite