Répondre à la FAQ d'Apache Cassandra

Depuis son développement en 2007, Apache Cassandra s'est forgé une réputation de magasin de données NoSQL solide, hautement évolutif et fiable, utilisé par certaines des plus grandes entreprises du monde. Mais il faut aussi un certain niveau d'expérience et d'expertise pour travailler avec Cassandra. Il est donc compréhensible que de nombreuses questions se posent lors de l'apprentissage de cette base de données open source.

Cet article couvre certaines des principales questions que les développeurs posent sur divers forums communautaires.

Quelle est la différence entre la partition, le clustering et les clés composites dans Cassandra ?

Comprendre en quoi la clé primaire dans les bases de données à colonnes étendues est différente des clés primaires relationnelles est une étape critique pour apprendre à utiliser le pouvoir de Cassandra.

Les magasins à colonnes larges comme Cassandra utilisent la notion de familles de colonnes, un objet de base de données qui contient plusieurs colonnes de données associées qui sont utilisées ensemble, similaires aux tables de base de données relationnelles traditionnelles. Dans une famille de colonnes donnée, toutes les données sont stockées ligne par ligne, de sorte que les colonnes d'une ligne donnée soient stockées ensemble, plutôt que chaque colonne soit stockée séparément.

Autrement dit, une famille de colonnes est une paire clé-valeur, où la clé est mappée à une valeur qui est un ensemble de colonnes. Pour faire une analogie avec les bases de données relationnelles, une famille de colonnes est comme une "table", chaque paire clé-valeur étant une "ligne". Pour les développeurs, les tableaux à colonnes larges peuvent se présenter comme un tableau à lignes et colonnes familier et facile à utiliser, dans le code ou via des API.

Regardons quelques exemples de code pour aider à donner vie aux concepts.

Dans le code ci-dessus, nous avons un espace clé, des champs comme "ville", "nom de famille" et "prénom". La clé primaire est en bas. Soit dit en passant, toutes les tables de Cassandra doivent inclure au moins une clé de partition. Dans l'exemple mis en évidence par l'image ci-dessus, nous partitionnerons par "ville".

Tout ce qui suit est une colonne de cluster. Remarquez les parenthèses autour de "ville" - cela indique qu'il s'agit de la clé de partition. Nous utilisons les parenthèses pour indiquer quelle est la clé de partition, dans le cas où votre clé de partition est composite et comporte plus d'une colonne. Ensuite, il est clair quelles colonnes sont pour les clés primaires et lesquelles sont des colonnes de clustering.

L'objectif principal de la clé primaire est de s'assurer qu'une ligne est unique. Il peut également contenir zéro ou plusieurs colonnes de clustering, qui peuvent contrôler le tri. Mais la clé primaire peut également être "composite" ou "composée", ce qui signifie qu'elle comporte deux colonnes ou plus.

La clé de partition est utilisée pour partitionner nos lignes et comporte une ou plusieurs colonnes.

Comment Cassandra trouve-t-elle le nœud contenant les données que je veux ?

Certaines personnes semblent penser que les clients pilotes envoient simplement des données à un nœud aléatoire. Mais il y a vraiment une manière non aléatoire pour que votre chauffeur choisisse un nœud à qui parler. Ce nœud s'appelle le nœud coordinateur. Il est généralement choisi parce qu'il est le plus proche.

Les demandes des clients peuvent être envoyées à n'importe quel nœud - et dans un premier temps, elles sont envoyées aux nœuds que votre pilote connaît. Mais une fois que le logiciel du pilote se connecte et comprend la topologie de votre cluster, il peut passer à un coordinateur plus proche. Découvrez le projet d'écosystème open source Stargate pour découvrir comment le calcul et le stockage peuvent être séparés pour l'évolutivité.

Les nœuds d'un cluster Cassandra open source échangent des informations de topologie entre eux à l'aide du protocole Gossip. Le bavardage s'exécute toutes les secondes et garantit que tous les nœuds sont tenus à jour avec les données du mouchard que vous avez configuré. Le snitch garde une trace des centres de données et des racks auxquels appartient chaque nœud. De cette manière, le nœud coordinateur dispose également de données sur les nœuds responsables de chaque plage de jetons.

Vous pouvez voir ces informations en exécutant un outil de nœud "ring" à partir de la ligne de commande, bien que si vous utilisez des nœuds virtuels ou des "vnodes", ce sera un peu plus difficile à vérifier car les données sur les 256 nœuds virtuels (la valeur par défaut quantité) clignotera assez rapidement à l'écran.

Sur K8ssandra.io , ce comportement est davantage natif de Kubernetes et Etcd est utilisé à la place du protocole Gossip pour propager les métadonnées du cluster, ainsi que les mises à jour de schéma sécurisées.

Comment fonctionnent les index secondaires dans Cassandra ?

L'indexation est assez subtile. Cela aide à comprendre les composants internes de la base de données. Comment cette requête fonctionnerait-elle en interne dans Cassandra ? Jetez un oeil à cet exemple de code :

Comment cette requête fonctionnerait-elle en interne dans Cassandra ?

Essentiellement, toutes les données de la partition avec l'ID de portée égal à 35 et l'ID de formulaire égal à 78005 seraient renvoyées, puis elles seraient filtrées par l'index d'ID de lien d'enregistrement. Il recherchera ou l'entrée d'ID d'index d'enregistrement pour 9897 et tentera de faire correspondre les entrées qui correspondent aux lignes renvoyées où l'ID de portée est égal à 35 et l'ID de formulaire est égal à 78005. L'intersection des lignes pour les clés de partition et les clés d'index sera renvoyée .

Vous pourriez raisonnablement vous demander si une colonne à cardinalité élevée comme l'index d'ID de lien d'enregistrement affecterait les performances de la requête pour cela. Les indices de cardinalité élevée créent essentiellement une ligne pour presque chaque entrée de la table principale. Les performances peuvent être affectées car Cassandra est conçu pour les lectures séquentielles des résultats de requête. Une requête d'index oblige essentiellement Cassandra à effectuer des lectures aléatoires à mesure que la cardinalité de votre index augmente, tout comme le temps nécessaire pour trouver la valeur interrogée.

Alors, Cassandra toucherait-elle tous les nœuds pour la requête ci-dessus ? Non, il ne doit toucher qu'un nœud responsable de cet ID de portée égal à 35 et de cet ID de formulaire égal à 78005 partition. De même, les index sont stockés localement et ne contiennent que des entrées valides pour le nœud local.

Quelle est la différence entre Cassandra et DataStax Astra DB ?

Cassandra est une base de données NoSQL open source qui alimente les applications distribuées que vous utilisez probablement tous les jours, à grande échelle. Cependant, c'est à vous et à votre équipe de vous autogérer.

Astra DB , d'autre part, est une base de données sans serveur en tant que service. Il s'agit d'un service cloud entièrement géré et à mise à l'échelle automatique, basé sur Cassandra et exécuté sur un fournisseur de cloud public de votre choix.

Avec l'ajout de la passerelle d'API de données open source Stargate , Cassandra et Astra DB servent des charges de travail NoSQL de document, de colonne et de clé-valeur. Et avec Astra DB, Stargate est automatiquement configuré pour vous.

Vous voulez en savoir plus sur Cassandre ? Rejoignez-nous à Cassandra Forward , un événement numérique gratuit le 14 mars !