L'Apache Software Foundation a présenté la version du SGBD distribué Apache Cassandra 4.0, qui appartient à la classe des systèmes noSQL et est conçu pour créer un stockage hautement évolutif et fiable d'énormes quantités de données stockées sous la forme d'un tableau associatif (hachage). La version Cassandra 4.0 est considérée comme prête pour la mise en œuvre en production et a déjà été testée dans les infrastructures d'Amazon, Apple, DataStax, Instaclustr, iland et Netflix avec des clusters de plus de 1000 2.0 nœuds. Le code du projet est écrit en Java et est distribué sous la licence Apache XNUMX.
Le SGBD Cassandra a été initialement développé par Facebook et transféré en 2009 sous les auspices de la Fondation Apache. Des solutions industrielles basées sur Cassandra ont été déployées pour alimenter les services d'entreprises telles que Apple, Adobe, CERN, Cisco, IBM, HP, Comcast, Disney, eBay, Huawei, Netflix, Sony, Rackspace, Reddit et Twitter. Par exemple, l'infrastructure de stockage basée sur Apache Cassandra déployée par Apple compte plus d'un millier de clusters, dont 160 100 nœuds et stockant plus de 300 pétaoctets de données. Huawei utilise plus de 30 clusters Apache Cassandra, comprenant 100 10 nœuds, et Netflix utilise plus de XNUMX clusters, couvrant XNUMX XNUMX nœuds et traitant plus d'un billion de requêtes par jour.
Le SGBD Cassandra combine un système de hachage Dynamo entièrement distribué, qui offre une évolutivité presque linéaire à mesure que le volume de données augmente. Cassandra utilise un modèle de stockage de données basé sur une famille de colonnes (ColumnFamily), qui se distingue des systèmes comme memcachedb, qui stockent les données uniquement dans une chaîne clé/valeur, par la possibilité d'organiser le stockage des hachages avec plusieurs niveaux d'imbrication. Pour simplifier l'interaction avec la base de données, le langage de requête structuré CQL (Cassandra Query Language) est pris en charge, qui rappelle SQL, mais avec des fonctionnalités réduites. Les fonctionnalités incluent la prise en charge des espaces de noms et des familles de colonnes, ainsi que la création d'index à l'aide de l'expression « CREATE INDEX ».
Le SGBD vous permet de créer un stockage résistant aux pannes : les données placées dans la base de données sont automatiquement répliquées sur plusieurs nœuds d'un réseau distribué, qui peut s'étendre sur différents centres de données. Lorsqu'un nœud tombe en panne, ses fonctions sont reprises à la volée par d'autres nœuds. L'ajout de nouveaux nœuds au cluster et la mise à jour de la version Cassandra se font à la volée, sans intervention manuelle supplémentaire ni reconfiguration d'autres nœuds. Les pilotes prenant en charge CQL sont préparés pour Python, Java (JDBC/DBAPI2), Ruby, PHP, C++ et JavaScript (Node.js).
Principales nouveautés :
- Performances et évolutivité améliorées. L'efficacité de l'échange de données au format SSTable (Sorted Strings Table) entre nœuds a été améliorée. Le protocole de messagerie inter-nœuds a été optimisé. La vitesse de transfert des flux de données entre les nœuds a augmenté jusqu'à 5 fois (principalement en raison de l'utilisation de la technique Zero Copy et du transfert de SSTables entières), et le débit des opérations de lecture et d'écriture a augmenté jusqu'à 25 %. Le processus de récupération incrémentielle a été optimisé. Les latences dues à la pause du garbage collection sont réduites à quelques millisecondes.
- Ajout de la prise en charge d'un journal d'audit qui vous permet de suivre les opérations d'authentification des utilisateurs et toutes les requêtes CQL exécutées.
- Ajout de la possibilité de conserver un journal complet des requêtes binaires, vous permettant de sauvegarder tout le trafic de requêtes et de réponses. Pour la gestion, les commandes « nodetool activatefullquerylog|disablefullquerylog|resetfullquerylog » sont proposées, et l'utilitaire fqltool est fourni pour l'analyse des logs. Des commandes sont fournies pour convertir le journal sous une forme lisible (Dump), comparer les tranches d'activité (Comparer) et réexécuter (Replay) pour une analyse reproduisant les conditions inhérentes à la charge réelle.
- Ajout de la prise en charge des tables virtuelles qui reflètent non pas les données stockées dans les SSTables, mais les informations sorties via l'API (mesures de performances, informations sur les paramètres, contenu du cache, informations sur les clients connectés, etc.).
- L'efficacité du stockage des données compressées a été améliorée, réduisant la consommation d'espace disque et améliorant les performances de lecture.
- Les données liées à l'espace de clés système (system.*) sont désormais placées par défaut dans le premier répertoire au lieu d'être réparties dans tous les répertoires de données, ce qui permet au nœud de rester opérationnel en cas de panne de l'un des disques supplémentaires.
- Ajout d'un support expérimental pour la réplication transitoire et les quorums bon marché. Les réplicas temporaires ne stockent pas toutes les données et utilisent la restauration incrémentielle pour être cohérents avec les réplicas complets. Les quorums légers implémentent une optimisation de l'écriture dans laquelle aucune écriture n'est effectuée sur les réplicas temporaires jusqu'à ce qu'un ensemble suffisant de réplicas complets soit disponible.
- Ajout du support expérimental pour Java 11.
- Ajout d'une option expérimentale pour comparer tous les arbres Merkle. Par exemple, l'activation de l'option sur un cluster à 3 nœuds dans lequel deux réplicas sont identiques et un est obsolète entraînera une mise à jour du réplica obsolète en utilisant une seule opération de copie du réplica actuel.
- Ajout de nouvelles fonctions currentTimestamp, currentDate, currentTime et currentTimeUUID.
- Ajout de la prise en charge des opérations arithmétiques dans les requêtes CQL.
- La possibilité d'effectuer des opérations arithmétiques entre des données de type « horodatage »/« date » et « durée » est fournie.
- Ajout d'un mode de prévisualisation des flux de données requis pour la récupération (nodetool repair —preview) et de la possibilité de vérifier l'intégrité des données en cours de restauration (nodetool repair — validate).
- Les requêtes SELECT ont désormais la possibilité de traiter les éléments Map et Set.
- Ajout de la prise en charge de la parallélisation de l'étape de construction initiale des vues matérialisées (cassandra.yaml:concurrent_materialized_view_builders).
- La commande "nodetool cfstats" a ajouté la prise en charge du tri selon certaines métriques et la limitation du nombre de lignes affichées.
- Des paramètres sont fournis pour limiter la connexion de l'utilisateur à certains centres de données uniquement.
- Ajout de la possibilité de limiter l'intensité (limite de taux) des opérations de création et d'effacement d'instantanés.
- cqlsh et cqlshlib prennent désormais en charge Python 3 (Python 2.7 est toujours pris en charge).
- La prise en charge de la plate-forme Windows a été interrompue. Pour exécuter Cassandra sous Windows, il est recommandé d'utiliser des environnements Linux créés sur la base du sous-système WSL2 (Windows Subsystem for Linux 2) ou des systèmes de virtualisation.
Source: opennet.ru