Gestion avancée des tables dans Cassandra

Dans les tutoriels précédents, nous sommes entièrement entrés avec CQL et la manière dont il nous aide à gérer Cassandre, nous avons vu les opérations de base pour le espaces clés et les tableaux dans Cassandra, nous pourrions les appliquer pour créer une structure initiale dans la base de données, mais il existe une quantité considérable de concepts avancés que nous devons connaître pour tirer le meilleur parti de Cassandra.
Ces concepts ou caractéristiques pour les appeler d'une manière ou d'une autre, nous permettent d'obtenir différentes fonctionnalités dans nos tables, nous offrant une gamme de possibilités beaucoup plus large que le reste des autres. Base de données NoSQL.
Auparavant, nous avons créé des tableaux et utilisé des valeurs comme du texte ou une date pour nos colonnes, mais ce n'est pas tout CQL dispose, voyons les types de données dont nous disposons pour nos opérations :
asciiChaîne de caractères US-ASCII.
bigintUne valeur entière de 64 bits.
goutteType de données exprimé en hexadécimal dans la console de commande de CQLDe plus, il n'a pas de validation et est basé sur des octets arbitraires.
booléenLe type de données booléen classique où ses valeurs peuvent être vraies ou fausses.
compteurcounter est un nouveau type de données pour ceux d'entre nous qui viennent du monde relationnel et indique qu'il est distribué sur 64 bits.
décimalUn autre type de données que nous pouvons reconnaître, ce qui nous donne une précision décimale pour nos informations.
doubleType de données à virgule flottante mais basé sur 64 bits.
flotterComme le précédent, il s'agit d'un type de données à virgule flottante mais basé sur 32 bits.
inetCe type est assez particulier et très utile à la fois et permet de stocker une chaîne de caractères d'une adresse IP, il supporte à la fois le format IPV4 Quoi IPV6.
entierLe type de données entier classique qui prend en charge les nombres jusqu'à 32 bits.
listeUn autre type de données qui fait ses débuts dans Cassandra et nous permet de stocker une collection ordonnée d'éléments.
carteComme list, c'est un autre type de nouvelles données, et il nous permet de stocker un tableau associatif, ce qui est très utile pour le développement d'applications.
ensembleSemblable au type de données de liste, il stocke une collection d'éléments mais sans ordre spécifique.
texteStocke une chaîne de caractères codée.
horodatageType de données qui stocke la date et l'heure, codés sous forme d'entier de 8 octets.
varianteType de données de précision pour les entiers arbitraires.
Comme on peut le voir, il existe de nombreux types de données que nous pouvons reconnaître si nous venons du monde relationnel, comme d'autres que nous verrons pour la première fois et qui font Cassandre se démarque des autres bases de données.
Dans Cassandre nous avons non seulement des types de données pour nos tables, grâce à CQL Nous pouvons affecter aux tables de nos propriétés de base de données ce qui nous aide énormément dans les tâches de maintenance et de développement, voyons ce dont nous disposons.
Mise en cacheCette propriété nous donne une optimisation de la mémoire cache. Les niveaux disponibles pour cette propriété sont là ou tout le monde, keys_only ou juste des clés, lignes_seulement ou simplement des lignes et rien ou aucun. Toutes les options sont assez utiles, cependant row_only doit être utilisé avec précaution car Cassandre mettre une quantité considérable de données en mémoire lorsque cette option est utilisée.
CommenterOption présente dans le modèle relationnel et utilisée par les administrateurs ou les développeurs pour prendre des notes et mettre en évidence des détails importants dans les tableaux.
CompactageCette propriété permet de définir la stratégie de gestion des menthe, peut être des types suivants : Le premier TailleÉtage qui se déclenche lorsque la table dépasse une limite, l'avantage d'utiliser cette stratégie est qu'elle ne dégrade pas les performances d'écriture, cependant elle a un inconvénient est qu'elle utilise parfois deux fois la taille des données sur le disque, ce qui entraîne des performances médiocres en train de lire. La deuxième stratégie est Compactage nivelé et cela fonctionne à différents niveaux au fil du temps, joignant des tables avec des tables plus longues, ce qui se traduit par de très bonnes performances de lecture.
CompressionCette propriété détermine comment les informations seront compressées. Nous pouvons choisir d'obtenir des avantages en termes de vitesse ou d'espace, où plus la vitesse est élevée, moins l'espace disque est économisé.
Gc_grace_secondsCette propriété définit le temps d'attente pour supprimer les informations des objets tombstone. Par défaut, il est de 10 jours.
Populate_io_cache_on_flushCette propriété est désactivée par défaut et nous ne devons l'activer que si nous espérons que toutes les informations tiendront dans la mémoire cache.
Lecture_réparation_chanceUne propriété très intéressante qui indique un nombre compris entre 0 et 1,0 spécifiant la probabilité de réparer l'information lorsque le quorum n'est pas atteint. La valeur par défaut est 0,1.
Replicate_on_writeCette propriété s'applique uniquement aux tables de type compteur. Lorsqu'elles sont définies, les répliques écrivent sur toutes les répliques affectées, en ignorant le niveau de cohérence spécifié.
Donc, nous savons déjà ce que nous avons, à la fois au niveau des types de données et des propriétés, il est temps alors d'appliquer certaines des choses apprises à nos tables dans Cassandre.
Nous allons d'abord créer un tableau simple auquel nous appliquerons la propriété comments, voyons la syntaxe que nous utiliserons pour cela :

 CREATE TABLE articles (titre du texte, contenu du texte, catégorie de texte, PRIMARY KEY (titre)) WITH comment = 'Table pour stocker les informations sur l'article';

Nous ouvrons notre console de commande CQL et nous créons notre table avec la propriété mentionnée, voyons à quoi cela ressemble :

Comme nous le savons déjà, la console de commande ne renvoie rien sauf qu'il n'y a pas d'erreur, mais si nous voulons voir ces changements, nous pouvons aller à notre Centre des opérations et vérifiez que tout s'est bien passé :

AGRANDIR

Comme nous pouvons le voir, nous pouvons voir notre commentaire et d'autres propriétés avec leurs valeurs par défaut. Il est important de mentionner que la définition du reste des propriétés dans Cassandre c'est assez simple, comme on a pu le voir avec l'exemple précédent, en utilisant la syntaxe AVEC nous pouvons le faire sans aucun problème.
Nous allons réaliser un autre exemple où nous allons définir les propriétés compression Oui compactage mais pour cela il est important de savoir qu'ils ont une série de sous options pour leur utilisation, voyons pour compression que l'on doit savoir :
Compression_stableCette option précise l'algorithme de compression à utiliser, ses valeurs sont : Compresseur LY4, Compresseur Snappy, Oui Dégonfler le compresseur.
Chunck_length_kbLes tableaux sont compressés par blocs. Des valeurs plus longues offrent généralement une meilleure compression mais augmentent la taille des informations à lire. Par défaut, cette option est définie sur 64 ko.
La manipulation des options de compression peut entraîner une augmentation significative des performances, y compris de nombreuses implémentations de Cassandre Ils sont avec ces valeurs par défaut, mais pour la perfection, il est nécessaire d'utiliser ces valeurs. Voyons maintenant ce que nous devons savoir pour compactage :
ActivéeDétermine si la propriété s'exécutera dans la table bien que par défaut toutes les propriétés aient compactage activée.
ClasserNous allons définir ici le type de stratégie de manipulation des tables.
min_seuilCette valeur est disponible avec la stratégie TailleÉtage y représente le nombre minimum de tables nécessaires pour démarrer un processus de compactage. Il est défini par défaut à 4.
seuil_maxDisponible de la même manière dans la stratégie TailleÉtage y définit le nombre maximum de tables traitées dans le compact. Il est défini par défaut à 32.
Ce sont quelques-unes des options les plus importantes pour ces propriétés, ce qui est important de mentionner est que pour la définition de ces options, nous devons utiliser une syntaxe JSON Pour être valide, voyons un exemple de l'inclusion de ces deux propriétés :

 CREATE TABLE table_for_properties (int id, text name, text property, varint number, PRIMARY KEY (id)) WITHcompression = {'sstable_compression': 'DeflateCompressor', 'chunk_length_kb': 64} ANDcompaction = {'class': 'SizeTieredCompactionStrategy', 'min_threshold' : 6};

Comme nous pouvons le voir, nous avons changé le type de compression et nous en avons défini la taille, en plus pour compactage nous avons laissé la stratégie habituelle avec la valeur classer et nous avons défini le min_seuil comme 6 a augmenté la valeur par défaut comme ceci, pour finir, voyons à quoi cela ressemble lorsque nous l'exécutons dans notre console de commande :

Dans le dernier tutoriel, nous avons pu voir qu'à la suite de la définition de plusieurs clés primaires, celles-ci sont créées en tant que clés de regroupement et dis nous le chemin Cassandre trie les informations, par défaut l'ordre est défini dans l'ordre croissant et faire une requête dans l'ordre décroissant pourrait causer des problèmes de performances, cependant Cassandra a une solution à tout problème et c'est avec la phrase CLUSTERING ***** PAR. Voyons comment l'utiliser.

 CREATE TABLE order_users (texte utilisateur, horodatage de la date, salaire flottant, texte du département, texte du superviseur, PRIMARY KEY (utilisateur, date)) AVEC CLUSTERING ***** BY (date DESC);

Exécutons notre syntaxe dans la console de commande et voyons à quoi cela ressemble :

Comme nous avons pu le voir, il était assez facile de résoudre ce problème avec une simple ligne, mais plus important encore, nous avons pu étendre nos connaissances en matière de gestion des tables dans Cassandre, avec lequel nous terminons ce didacticiel, où nous avons couvert tout ce que nous devons savoir pour une création de table optimale dans Cassandre.