Cassandra : base de données hautement évolutive prête à l'emploi

Cassandra est une base de données à colonnes larges distribuée, décentralisée, évolutive et hautement disponible.

En termes de théorème CAP, Cassandra signifie AP (disponibilité et tolérance de partition).

Cela signifie que Cassandra préfère que tous les clients puissent trouver des données même dans les cas où tous les nœuds ne sont pas disponibles et fonctionneront comme prévu en cas de panne partielle du réseau. Cependant, cela signifie également que la cohérence des données peut être compromise en faveur de la disponibilité et de la tolérance de partitionnement : les utilisateurs verront les données, mais elles pourront être obsolètes pendant un certain temps.

Cassandra est conçu pour atteindre un débit élevé et des opérations d'écriture plus rapides.

Et c’est précisément en sacrifiant la cohérence que Cassandra peut être hautement disponible.

Cassandra, étant une base de données NoSQL, ne prend pas en charge les jointures de tables, les clés étrangères ou la possibilité d'ajouter des colonnes autres que la clé primaire dans la clause WHERE lors de l'interrogation. Ces limitations doivent être prises en considération avant de choisir d'utiliser Cassandra.

Cassandra Blocs de construction

• Colonne : Une colonne représente une paire clé-valeur et sert d'unité fondamentale de la structure des données.
• Row : agit comme un conteneur pour les colonnes référencées par la clé primaire.
• Keyspace : sert de conteneur pour les tables qui s'étendent sur un ou plusieurs nœuds Cassandra.
• Cluster : un conteneur d'espaces de clés au sein de Cassandra.
• Nœud : fait référence à un système informatique qui exécute une instance de Cassandra. Un nœud peut être un hôte physique, une instance de machine dans le cloud ou même un conteneur Docker.

Comment Cassandra stocke les données

Cassandra stocke les données sous forme de famille de colonnes. Il sert de conteneur pour les colonnes référencées par une clé primaire.

Une ligne d'une famille de colonnes comprend plusieurs colonnes avec clé et valeur, et la clé de ligne sert de clé primaire :

Une famille de colonnes peut stocker un ensemble différent de colonnes pour chaque clé de ligne :

Quelle est la clé primaire dans Cassandra ?

La clé primaire identifie de manière unique chaque ligne d'une table. Dans Cassandra, la clé primaire comporte deux parties :

Dans Cassandra, la clé de partition détermine quel nœud stocke les données, tandis que la clé de clustering détermine comment les données sont stockées dans un nœud. Par exemple, considérons une table avec un

PRIMARY KEY (city_id, event_id) . Cette clé primaire se compose de deux parties, représentées par les deux colonnes :

1. city_id sert de clé de partition, ce qui signifie que les données seront partitionnées en fonction du champ city_id , ce qui entraînera le stockage de toutes les lignes avec le même city_id sur le même nœud.

2. event_id fait office de clé de clustering. Au sein de chaque nœud, les données sont organisées et stockées dans un ordre trié en fonction de la colonne event_id .

Chaque ligne avec partition key = "Paris" sera stockée sur le même nœud, triée par la valeur de la colonne event_id.

Partitionnement des données prêt à l'emploi

Cassandra fournit un partitionnement des données basé sur un hachage cohérent pour réduire la latence des opérations de lecture/écriture et augmenter le débit du système lorsque la quantité de données stockées dans la base de données devient importante.

Le partitionneur de Cassandra est chargé de décider de la manière dont les données sont distribuées dans l'anneau de hachage cohérent. Lorsque des données sont insérées dans un cluster Cassandra, le partitionneur applique un algorithme de hachage à la clé de partition . Le résultat de cet algorithme de hachage détermine la plage dans laquelle se situent les données et détermine le nœud sur lequel les données seront stockées.

Nœud coordinateur

Dans Cassandra, chaque nœud est conscient des attributions de jetons des autres nœuds via le protocole Gossip , permettant à n'importe quel nœud de gérer les demandes pour la plage de n'importe quel autre nœud. Par conséquent, un client peut se connecter à n’importe quel nœud pour lancer des requêtes de lecture ou d’écriture.

Le nœud qui reçoit la demande est appelé coordinateur et peut être n'importe quel nœud du cluster. Si une clé n'appartient pas à la plage du coordinateur, la demande est transmise aux réplicas responsables de cette plage.

Réplication

Cassandra réplique les données sur plusieurs nœuds pour garantir une haute disponibilité. Chaque nœud de Cassandra sert de réplique pour une plage de données spécifique. En répartissant plusieurs copies des données sur différentes répliques, Cassandra permet à d'autres répliques de gérer les requêtes pour cette plage de données au cas où un nœud serait indisponible. Deux paramètres affecteront le processus de réplication :

Le facteur de réplication détermine combien de nœuds stockeront des copies des mêmes données. Dans un cluster avec un facteur de réplication de 3, chaque ligne sera stockée sur trois nœuds différents.

Dans Cassandra, la première réplique est attribuée au nœud propriétaire de la plage en fonction du hachage de la clé de partition. Les répliques restantes sont ensuite placées sur des nœuds consécutifs dans le sens des aiguilles d'une montre. Cassandra utilise deux stratégies de réplication pour déterminer quels nœuds seront responsables des réplicas :

Stratégie de réplication simple

Dans cette stratégie, la première réplique est placée sur un nœud déterminé par le partitionneur, et les répliques suivantes sont placées sur les nœuds suivants dans le sens des aiguilles d'une montre.

Stratégie de topologie de réseau

Pour garantir la résilience contre la perte totale de données, des répliques supplémentaires au sein du même centre de données sont placées en se déplaçant dans le sens des aiguilles d'une montre le long de l'anneau jusqu'à atteindre le premier nœud dans un autre centre de données. Cette disposition permet d'atténuer l'impact des pannes simultanées qui se produisent généralement au sein du même centre de données en raison de problèmes d'alimentation, de refroidissement ou de réseau.

Quand utiliser Cassandra

Cassandra excelle dans les applications qui nécessitent de gérer de gros volumes de données et privilégient la disponibilité des données plutôt que la cohérence. Il est bien adapté pour :

1. Applications Internet des objets (IoT) : Cassandra est un choix idéal pour les environnements IoT, car elle peut gérer des quantités massives de données générées par les appareils et les capteurs. Son architecture distribuée permet de gérer des données géographiquement dispersées et à grande échelle.

2. Données de séries chronologiques : les applications traitant des données de séries chronologiques, telles que les métriques, les systèmes de surveillance et les données de télémétrie, bénéficient des opérations d'écriture efficaces et de l'évolutivité horizontale de Cassandra. Ces capacités sont cruciales pour stocker et gérer d’importants volumes de données horodatées.

3. Applications Web et mobiles : Cassandra offre un accès aux données à haut débit et à faible latence, ce qui le rend adapté aux plates-formes Web et mobiles avec de grandes bases d'utilisateurs générant des quantités importantes de données. Cela inclut les plateformes de médias sociaux, les applications de jeux et les sites de commerce électronique.

4. Analyse du Big Data en temps réel : Cassandra prend en charge le traitement en temps réel du Big Data, ce qui en fait un choix précieux pour les applications nécessitant des informations immédiates à partir de grands ensembles de données. Les exemples incluent les moteurs de recommandation et les systèmes de détection de fraude.

5. Entrepôts de données distribués : les entreprises disposant de grands ensembles de données distribués peuvent exploiter Cassandra comme solution d'entrepôt de données. Sa capacité à répliquer les données sur plusieurs centres de données garantit une haute disponibilité et une reprise après sinistre.

6. Systèmes de messagerie : le débit élevé d'écriture et de lecture de Cassandra le rend bien adapté aux systèmes de messagerie qui gèrent des volumes de données élevés, tels que la journalisation des événements, les pistes d'audit ou les files d'attente de messages.

7. Systèmes de personnalisation et de gestion de contenu : les applications nécessitant une diffusion de contenu personnalisé à grande échelle, telles que les systèmes de gestion de contenu, bénéficient de la rapidité et de l'évolutivité de Cassandra pour fournir simultanément du contenu personnalisé à un grand nombre d'utilisateurs.

8. Applications géographiquement distribuées : la prise en charge de plusieurs centres de données par Cassandra en fait un excellent choix pour les applications nécessitant des données géographiquement distribuées. Il garantit un accès aux données à faible latence dans différentes régions et offre une résilience élevée.

Quand ne pas utiliser Cassandra

Bien qu'Apache Cassandra soit puissant et évolutif, il peut ne pas convenir à toutes les applications ou cas d'utilisation. Il est moins adapté aux applications nécessitant de lourdes transactions, aux requêtes complexes et aux scénarios nécessitant une forte cohérence ou des changements de schéma rapides. Les systèmes de gestion de bases de données relationnelles (SGBDR) traditionnels ou d'autres solutions NoSQL peuvent être plus appropriés dans de tels cas. Voici plusieurs scénarios dans lesquels Cassandra pourrait ne pas être le choix optimal :

1. Projets à petite échelle : la complexité et les besoins en ressources de Cassandra peuvent être excessifs pour des projets ou des applications à petite échelle avec des ensembles de données limités. Des solutions de bases de données plus simples peuvent offrir une alternative plus rentable et plus gérable.

   
   

2. Systèmes transactionnels nécessitant des propriétés ACID : Cassandra ne prend pas entièrement en charge les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité). Si votre application nécessite des transactions complexes que l’on trouve généralement dans les systèmes bancaires ou financiers, un SGBDR traditionnel pourrait être mieux adapté.

   
   

3. Rejoindre des requêtes et des agrégations lourdes : si votre application repose fortement sur des jointures, des sous-requêtes ou des agrégations complexes, Cassandra n'est peut-être pas le choix le plus approprié. Il est conçu pour des écritures et des lectures rapides, mais pas pour le traitement de requêtes complexes.

   
   

4. Données avec de fortes exigences de cohérence : Cassandra fournit une cohérence éventuelle, qui peut ne pas convenir aux cas d'utilisation nécessitant une forte cohérence pour chaque opération de lecture et d'écriture.

   
   

5. Lectures et écritures à faible latence dans un seul cluster : bien que Cassandra fonctionne bien dans les environnements distribués à plusieurs nœuds, il n'est peut-être pas le choix optimal pour les déploiements à nœud unique ou en petit cluster qui nécessitent des lectures et des écritures à faible latence.

   
   

6. Stockage Blob : Cassandra n'est pas optimisé pour stocker de gros objets binaires (blobs) tels que des images ou des vidéos. D’autres solutions de stockage sont mieux adaptées pour gérer efficacement les gros blobs.

   
   

7. Applications nécessitant des requêtes ad hoc : les capacités de requête de Cassandra sont limitées par rapport aux bases de données SQL à part entière. Il n'est pas bien adapté aux applications qui s'appuient fortement sur des requêtes et des rapports ad hoc.

   Dans Cassandra, la conception des tables est étroitement liée à la manière dont les données seront accessibles, mettant l'accent sur les modèles de requête plutôt que sur les relations entre les entités de données. Cela diffère de l'approche du SGBDR, où la conception du schéma est basée sur des principes de normalisation.

   
   

8. Evolution rapide du schéma : si votre application nécessite des modifications fréquentes du schéma de base de données, la gestion du schéma de Cassandra peut être moins flexible par rapport aux systèmes SGBDR traditionnels ou à d'autres solutions NoSQL.

   
   

9. Applications d'entrepôt de données qui impliquent des requêtes complexes, des jointures et une analyse de données historiques : bien que Cassandra soit bien adapté aux charges de travail lourdes en écriture et à l'accès aux données en temps réel, il n'est peut-être pas le choix le plus approprié pour les scénarios d'entreposage de données qui nécessitent des requêtes complexes, jointures et analyse des données historiques.

Résumé

Cet article donne un aperçu de Cassandra, une base de données à colonnes larges hautement évolutive et distribuée. Cassandra est conçu pour donner la priorité à la disponibilité et à la tolérance de partitionnement, ce qui le rend adapté aux applications où la cohérence n'est pas une exigence critique. Il prend en charge un débit élevé et des opérations d'écriture plus rapides.

Les éléments constitutifs de Cassandra comprennent des colonnes, des lignes, des espaces de clés, des clusters et des nœuds. Les colonnes représentent des paires clé-valeur, les lignes agissent comme des conteneurs pour les colonnes référencées par la clé primaire, les espaces de clés servent de conteneurs pour les tables s'étendant sur plusieurs nœuds, les clusters contiennent des espaces de clés et les nœuds font référence aux systèmes informatiques exécutant des instances Cassandra.

Cassandra stocke les données dans des familles de colonnes, qui sont des conteneurs pour les colonnes référencées par une clé primaire. Le partitionnement des données est obtenu grâce à un hachage cohérent, permettant une latence réduite et un débit accru. Le partitionneur distribue les données sur l'anneau de hachage cohérent et un nœud coordinateur gère les requêtes de lecture et d'écriture.

Cassandra fournit une réplication pour une haute disponibilité. Les répliques de données sont stockées sur plusieurs nœuds, garantissant que les requêtes peuvent être traitées par les répliques si un nœud devient indisponible. Les facteurs et stratégies de réplication déterminent le nombre de réplicas et les nœuds qui en sont responsables.

Bien que Cassandra offre des avantages tels que l'évolutivité et la haute disponibilité, elle présente des limites. Il ne prend pas en charge les jointures de tables, les clés étrangères ou la possibilité d'ajouter des colonnes autres que la clé primaire dans la clause WHERE lors de l'interrogation.

Dans l'ensemble, Cassandra est une solution de base de données puissante pour les applications hautement évolutives, en particulier celles qui privilégient la disponibilité et la tolérance de partitionnement plutôt qu'une forte cohérence.

Acclamations!