Sortie de rqlite 7.0, une base de données distribué et résiliente fondée sur SQLite

La version 7.0 de la base de données distribuée rqlite a été publiée. Elle utilise SQLite comme moteur de stockage et permet de structurer un cluster d'entrepôts synchronisés. Parmi les caractéristiques de rqlite, on note la simplicité d'installation, de déploiement et d'entretien d'un entrepôt distribué tolérant aux pannes, similaire à etcd et Consul, mais adoptant un modèle relationnel de travail avec les données au lieu d'un format clé/valeur. Le code du projet est écrit en Go et est distribué sous licence MIT.

Pour maintenir tous les nœuds en état synchronisé, l'algorithme de consensus Raft est utilisé. Rqlite utilise la bibliothèque SQLite originale et le pilote go-sqlite3, sur lesquels s'exécute une couche traitant les requêtes des clients, réalisant la réplication vers d'autres nœuds et surveillant l'atteinte du consensus pour le choix du nœud leader.

Les modifications de la base de données ne peuvent être apportées que par le nœud désigné comme leader, mais les connexions pour les opérations d'écriture peuvent être envoyées à d'autres nœuds du cluster, qui renverront l'adresse du leader pour répéter la requête (la prochaine version promet d'ajouter un passage automatique à l'adresse du leader). L'accent est mis sur la tolérance aux pannes, c'est pourquoi la base de données ne se développe que pour les opérations de lecture, tandis que les opérations d'écriture constituent un goulet d'étranglement. Un cluster rqlite peut être lancé à partir d'un seul nœud, ce qui peut être utilisé pour organiser l'accès à SQLite via HTTP sans garantir de tolérance aux pannes.

Les données SQLite sur chaque nœud ne sont pas stockées dans un fichier, mais en mémoire. Au niveau de la couche implémentant le protocole Raft, un journal de toutes les commandes SQLite entraînant des modifications de la base de données est tenu. Ce journal est utilisé lors de la réplication (réplication au niveau de la reproduction des requêtes sur d'autres nœuds), au lancement d'un nouveau nœud ou pour la récupération après une perte de connectivité. Pour réduire la taille du journal, une compression automatique est appliquée, qui se déclenche après un certain nombre de modifications et conduit à la fixation d'un instantané, par rapport auquel un nouveau journal commence à être tenu (l'état de la base en mémoire est identique à l'instantané + le journal des modifications accumulées).

Caractéristiques de rqlite :

• Simplicité de déploiement du cluster, sans nécessiter d'installation séparée de SQLite.
• Possibilité d'obtenir rapidement un stockage SQL répliqué.
• Prêt à être utilisé dans des projets de production.
• Disponibilité d'une API HTTP(S) permettant de mettre à jour les données par lots et de définir le nœud principal du cluster. Une interface en ligne de commande et des bibliothèques clientes pour divers langages de programmation sont également fournies.
• Disponibilité d'un service pour identifier d'autres nœuds, permettant de créer des clusters de manière dynamique.
• Support du chiffrement des échanges de données entre les nœuds.
• Possibilité de configurer le niveau de vérification de l'actualité et de la cohérence des données lors de la lecture.
• Possibilité optionnelle de connecter des nœuds en mode lecture seule, ne participant pas à la détermination du consensus et utilisés pour augmenter la scalabilité du cluster pour les opérations de lecture.
• Support d'une forme propre des transactions basée sur la fusion de commandes dans une seule requête (les transactions basées sur BEGIN, COMMIT, ROLLBACK, SAVEPOINT et RELEASE ne sont pas supportées).
• Support de la création de sauvegardes à chaud.

Dans cette nouvelle version :

• Ajout du support du clustering automatique rqlite utilisant un nouveau service d'identification des nœuds, pouvant fonctionner sur des stockages distribués Consul et etcd. Le service permet aux nœuds rqlite de se trouver automatiquement — l'administrateur n'a qu'à lancer plusieurs nœuds sur différents serveurs, en indiquant l'adresse commune du cluster Consul ou etcd (par exemple, « example.com:8500 »), et les nœuds seront automatiquement groupés en cluster. Le nœud principal met régulièrement à jour dans le stockage Consul ou etcd son adresse, permettant de changer ensuite de leader sans reconfiguration des autres nœuds, ainsi que d'ajouter de nouveaux nœuds même après un changement de leader. Le support de l'ancien service d'identification des nœuds (Discovery mode) fonctionnant sur AWS Lambda est interrompu.
• Dans l'interface CLI, il est maintenant possible d'indiquer plusieurs hôtes — si le premier nœud est inaccessible, l'appel se fera aux hôtes suivants.
• Le code pour l'analyse des arguments de ligne de commande rqlited a été retravaillé.
• L'utilisation du paquet obsolète protobuf a été abandonnée.
• Le stockage BoltDB, utilisé dans la mise en œuvre du protocole Raft, a été remplacé par bbolt, un fork du projet etcd.

Source : opennet.ru