Catégories
Start-up et applications

Indexation Apache Cassandra sans avoir à dire que je suis désolé

Récemment, il y a eu une nouvelle proposition de changement pour l'indexation Cassandra qui tente de réduire le compromis entre utilisabilité et stabilité: rendre la clause WHERE beaucoup plus intéressante et utile pour les utilisateurs finaux. Cette nouvelle méthode s'appelle Storage-Attached Indexing (SAI). Ce n’est pas le nom le plus flashy, mais qu’attendez-vous? Les ingénieurs ne sont pas connu pour nommer des choses, mais la technologie cool n'est jamais une blague. SAI a attiré l'attention du Communauté Cassandra, mais pourquoi? L'indexation des données n'est pas un nouveau concept dans le monde des bases de données.

La manière dont nous indexons nos données peut changer au fil du temps en fonction des cas d'utilisation et des modèles de déploiement souhaités. Cassandra a été construit en combinant des aspects de Dynamo et Grande table pour réduire la complexité des frais généraux de lecture et d'écriture en gardant les choses simples. La complexité de Cassandra a été principalement réservée à sa nature distribuée et, par conséquent, a créé un compromis pour les développeurs. Si vous voulez l'ampleur incroyable de Cassandra, vous devez passer du temps à apprendre à modéliser des données. Les index de base de données sont destinés à améliorer votre modèle de données et à rendre vos requêtes plus efficaces. Pour Cassandra, ils existent sous une forme ou une autre depuis les débuts du projet. La triste réalité est qu’ils ne correspondent pas bien aux besoins des utilisateurs. Toute utilisation de l'indexation s'accompagne d'une longue liste de compromis et d'avertissements au point qu'ils sont pour la plupart évités et pour certains, tout simplement un non. En conséquence, les utilisateurs ont appris à modéliser des données avec des requêtes de base pour obtenir les meilleures performances.

Ces jours sont peut-être derrière nous et des fonctionnalités comme SAI nous aident à y parvenir.

Index secondaires dans les bases de données distribuées
Tous les index ne sont pas créés égaux. Les index primaires sont également connus sous le nom de clé unique, ou dans le vocabulaire Cassandra, clé de partition. En tant que méthode d'accès principale à la base de données, Cassandra utilise la clé de partition pour identifier le nœud contenant les données puis le fichier de données qui stocke la partition de données. Les lectures d'index primaires dans Cassandra sont assez simples mais dépassent le cadre de cet article. Vous pouvez en savoir plus sur eux ici.

Les index secondaires créent un défi complètement différent et unique dans une base de données distribuée. Examinons un exemple de tableau pour faire quelques remarques:

Les index secondaires créent un défi complètement différent et unique dans une base de données distribuée. Examinons un exemple de tableau pour faire quelques remarques:

Les index secondaires créent un défi complètement différent et unique dans une base de données distribuée. Examinons un exemple de tableau pour faire quelques remarques:

Les index secondaires créent un défi complètement différent et unique dans une base de données distribuée. Examinons un exemple de tableau pour faire quelques remarques:

CREATE TABLE utilisateurs (
id long,
texte firstName,
texte lastName,
texte du pays,
horodatage créé,
CLÉ PRIMAIRE (id)
);

Une recherche d'index primaire serait assez simple comme ceci:
SELECT firstName, lastName FROM utilisateurs WHERE id = 100;

Et si je voulais retrouver tout le monde en France? En tant que familiarisé avec SQL, vous vous attendez à ce que cette requête fonctionne:
SELECT firstName, lastName FROM utilisateurs WHERE country = 'FR';

Sans créer un index secondaire dans Cassandra, cette requête échouera. Le modèle d'accès fondamental dans Cassandra est par clé de partition. Dans une base de données non distribuée comme un SGBDR traditionnel, chaque colonne de la table est facilement visible par le système. Vous pouvez toujours accéder à la colonne même s'il n'y a pas d'index car ils existent tous dans le même système et les mêmes fichiers de données. Les index dans ce cas aident à réduire le temps de requête en rendant la recherche plus efficace.

Dans un système distribué comme Cassandra, les valeurs de colonne se trouvent sur chaque nœud de données et doivent être incluses dans le plan de requête. Ceci met en place ce que nous appelons le scénario «Scatter-Gather» où une requête est envoyée à chaque nœud, les données sont collectées, fusionnées et renvoyées à l'utilisateur. Même si cette opération peut être effectuée sur plusieurs nœuds à la fois, la gestion de la latence dépend de la vitesse à laquelle le nœud peut trouver la valeur de la colonne.

Examen rapide des écritures de données Cassandra
Vous pensez peut-être que l'ajout d'index consiste à lire des données, ce qui est certainement l'objectif final. Cependant, lors de la création d'une base de données, les défis techniques de l'indexation sont biaisés au moment où les données sont écrites. Accepter les données à la vitesse la plus rapide tout en formatant les index sous la forme la plus optimale pour les lectures est un défi de taille. Cela vaut la peine de passer rapidement en revue la manière dont les données sont écrites dans une base de données Cassanda au niveau du nœud individuel. Reportez-vous au diagramme suivant pour expliquer comment cela fonctionne.

Lorsque les données sont présentées à un nœud, que nous appelons une mutation, le chemin d'écriture de Cassandra est très simple et optimisé pour cette opération. Ceci est également vrai pour de nombreuses autres bases de données basées sur Arborescences de fusion structurée en journal (LSM).

  1. Valider les données est le format correct. Vérifiez le type par rapport au schéma.
  2. Écrivez des données dans la queue d'un journal de validation. Pas de recherche, juste le point suivant sur le pointeur de fichier.
  3. Ecrivez des données dans une table mémoire, qui n'est qu'un hashmap du schéma en mémoire.

Terminé! La mutation est reconnue lorsque ces choses se produisent. J'adore la simplicité de ce processus par rapport à d'autres bases de données qui nécessitent un verrou et cherchent à effectuer une écriture.

Plus tard, lorsque les tables mémoire remplissent la mémoire physique, un processus de vidage écrit des segments en un seul passage sur le disque dans un fichier appelé SSTable (Sorted Strings Table). Le journal de validation d'accompagnement est supprimé maintenant que la persistance a été déplacée vers le SSTable. Ce processus se répète à mesure que les données sont écrites sur le nœud.

Détail important: Les SSTables sont immuables. Une fois qu'ils sont écrits, ils ne sont jamais mis à jour, juste remplacés. Finalement, à mesure que davantage de données sont écrites, un processus d'arrière-plan appelé compactage fusionne et trie les sstables en de nouvelles qui sont également immuables. Il existe de nombreux schémas de compactage, mais fondamentalement, ils remplissent tous cette fonction.

Vous avez maintenant suffisamment de bases sur Cassandra pour que nous puissions devenir suffisamment ringards avec les index. Toute autre profondeur d'information est laissée comme un exercice pour le lecteur.

Problèmes d'indexation précédente
Cassandra a eu deux implémentations d'indexation secondaire précédentes. Indexation secondaire associée au stockage (SASI) et index secondaires, que nous appelons 2i. Encore une fois, mon point sur le fait que les ingénieurs ne sont pas voyants avec des noms tient ici. Les index secondaires font partie de Cassandra depuis le début, mais les implémentations les ont compliqués pour les utilisateurs finaux avec leur longue liste de compromis. Les deux principales préoccupations que nous avons constamment traitées en tant que projet sont l'amplification de l'écriture et la taille de l'index sur le disque. En conséquence, ils peuvent être frustrants pour les nouveaux utilisateurs, mais ils échouent plus tard dans le déploiement. Regardons chacun d'eux.

Index secondaires (2i) – Ce travail original dans le projet a commencé comme une fonctionnalité pratique pour les premiers modèles de données Thrift. Plus tard, lorsque Cassandra Query Language a remplacé Thrift comme méthode de requête préférée pour Cassandra, la fonctionnalité 2i a été conservée avec la syntaxe «CREATE INDEX». Si vous veniez de SQL, c'était un moyen très simple d'apprendre la loi des conséquences involontaires. Tout comme dans l'indexation SQL, plus vous en ajoutez, plus vous affectez les performances d'écriture. Cependant, avec Cassandra, cela a déclenché le plus gros problème avec l'amplification d'écriture. En se référant au chemin d'écriture ci-dessus, les index secondaires ont ajouté une nouvelle étape dans le chemin. Lorsqu'une mutation sur une colonne indexée se produit, une opération d'indexation est déclenchée qui réindexe les données dans un fichier d'index distinct. Plus d'index sur une table peut augmenter considérablement l'activité du disque en une seule opération d'écriture sur une seule ligne. Lorsqu'un nœud subit une grande quantité de mutations, le résultat peut être une activité de disque saturée qui peut rendre les nœuds individuels instables, donnant à 2i les conseils mérités «à utiliser avec parcimonie». La taille de l'index est assez linéaire dans cette implémentation, mais avec la réindexation, la quantité d'espace disque nécessaire peut être difficile à planifier dans un cluster actif.

Indexation secondaire associée au stockage (SASI) – SASI a été initialement conçu par une petite équipe d'Apple pour résoudre un problème de requête spécifique et non le problème général des index secondaires. Pour être juste envers cette équipe, il leur a échappé dans un cas d'utilisation qu'il n'a jamais été conçu pour résoudre. Bienvenue à tout le monde open source. Les deux types de requêtes que SASI a été conçu pour traiter:

  • Recherche de lignes en fonction d'une correspondance partielle des données. Requêtes génériques ou LIKE.
  • Requêtes de plage sur des données éparses, en particulier des horodatages. Combien d'enregistrements tiennent dans une requête de type plage de temps.

Il a très bien fait ces deux opérations et a également résolu le problème de l'amplification en écriture avec legacy 2i. Au fur et à mesure que les mutations sont présentées à un nœud Cassandra, les données sont indexées en mémoire lors de l'écriture initiale, tout comme la façon dont les tables mémorielles sont utilisées. Aucune activité de disque n'est requise sur une permutation. Une énorme amélioration sur les clusters avec beaucoup d'activité d'écriture. Lorsque les memtables sont vidés dans sstables, l'index correspondant pour les données est vidé. Chaque fichier d'index écrit est immuable et attaché au sstable, d'où le nom Storage Attached. Lors du compactage, les données sont réindexées et écrites dans un nouveau fichier au fur et à mesure que de nouvelles sstables sont créées. Du point de vue de l'activité disque, il s'agissait d'une amélioration majeure. L'inconvénient de SASI résidait principalement dans la taille des index créés. Le format d'index sur disque a provoqué une énorme quantité d'espace disque utilisé pour chaque colonne indexée. Cela les rend très difficiles à gérer pour les opérateurs. De plus, SASI a été marqué comme expérimental et peu de choses se sont passées en ce qui concerne l'amélioration des fonctionnalités. De nombreux bogues ont été trouvés au fil du temps avec des correctifs coûteux qui ont amené la discussion sur la question de savoir si SASI devrait être complètement supprimé. Si vous avez besoin d'une plongée plus approfondie sur cette fonctionnalité, Duy Hai Doan a fait un travail incroyable de décomposer le fonctionnement de SASI.

Ce qui rend SAI meilleur
La première et la meilleure réponse à cette question est que l'ISC est de nature évolutive. Les ingénieurs de DataStax ont réalisé que l'architecture de base de l'indexation secondaire devait être abordée à partir de zéro, mais avec de solides leçons tirées des implémentations précédentes. La principale mission était de résoudre les problèmes d'amplification d'écriture et de taille de fichier d'index tout en créant un chemin pour de meilleures améliorations des requêtes dans Cassandra. Comment SAI aborde-t-elle ces deux sujets?

Amplification d'écriture – Comme nous l'avons appris de SASI, l'indexation en mémoire et le vidage des index avec SSTables était le bon moyen de rester en phase avec le fonctionnement du chemin d'écriture Cassandra, tout en ajoutant de nouvelles fonctionnalités. Avec SAI, lorsque la mutation est acquittée, c'est-à-dire entièrement engagée, les données sont indexées. Grâce aux optimisations et à de nombreux tests, l'impact sur les performances d'écriture s'est considérablement amélioré. Vous devriez voir mieux qu'une augmentation de 40% du débit et plus de 200% de meilleures latences d'écriture par rapport à 2i. Cela étant dit, vous devez toujours prévoir une augmentation de la latence et du débit 2x sur les tables indexées par rapport aux tables non indexées. Pour citer Duy Hai Doan, «Il n'y a pas de magie», juste une bonne ingénierie.

Taille de l'index – Il s'agit de l'amélioration la plus spectaculaire et sans doute là où la plupart des travaux ont été effectués. Si vous suivez le monde des internes de bases de données, vous savez que le stockage de données est toujours un domaine animé rempli d'améliorations en constante évolution. SAI utilise deux types différents de schémas d'indexation basés sur le type de données.

  • Texte – Les index inversés sont créés avec des termes décomposés dans un dictionnaire. La plus grande amélioration provient de l'utilisation de Trie indexation basée qui offre une bien meilleure compression, ce qui signifie des tailles d'index plus petites.
  • Numérique – En utilisant une structure de données appelée bloquer les arbres kd, tiré de Lucene, qui offre d'excellentes performances de requête de plage. Une liste d'ID de ligne distincte est conservée pour optimiser les requêtes de commande de jetons.

En mettant fortement l'accent sur le stockage d'index, le résultat a été une amélioration massive du volume par rapport au nombre d'index de table. Comme vous pouvez le voir dans le graphique ci-dessous, l'indexation rapide apportée par SASI a été rapidement éclipsée par l'explosion de l'utilisation du disque. Non seulement cela compliquait la planification opérationnelle, mais les fichiers d'index devaient être lus pendant les événements de compactage qui pouvaient saturer les disques et entraîner des problèmes de performances des nœuds.

En dehors de l'amplification d'écriture et de la taille de l'index, l'architecture interne de SAI permet une extension et des fonctionnalités supplémentaires à l'avenir. Ceci est conforme aux objectifs du projet d'être plus modulaire dans les futures versions. Jetez un œil à certains des autres CEP qui sont en attente et vous pouvez voir que ce n'est que le début.

Où va SAI à partir d'ici?
DataStax a proposé SAI au projet Apache Cassandra via le processus d'amélioration Cassandra en tant que CEP-7. La discussion est en cours pour l'inclusion dans la branche 4.x de Cassandra.

Si vous souhaitez essayer ceci maintenant avant qu'il ne fasse partie du projet Apache Cassandra, nous avons quelques endroits où vous pouvez aller. Pour les opérateurs ou les personnes qui aiment un peu plus de technicité, vous pouvez Télécharger la dernière version de DataStax Enterprise 6.8. Si vous êtes un développeur, SAI est désormais activé dans DataStax Astra, notre Cassandra en tant que service. Vous pouvez créer un niveau gratuit pour toujours pour jouer avec la syntaxe et la nouvelle fonctionnalité de clause where. Avec cela, apprenez à utiliser cette fonctionnalité en accédant au Page des compétences d'indexation Cassandra et inclus Documentation.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *