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. Par défaut, Cassandra est conçue pour être cohérente à terme, ce qui signifie qu'elle peut ne pas fournir une forte cohérence. Cela rend Cassandra adapté aux applications où la cohérence n'est pas une exigence critique. Cependant, il est possible de configurer Cassandra pour fournir une forte cohérence, même si cela peut avoir un impact sur les performances. 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 : Une colonne représente une paire clé-valeur et sert d'unité fondamentale de la structure des données. Colonne : agit comme un conteneur pour les colonnes référencées par la clé primaire. Row : sert de conteneur pour les tables qui s'étendent sur un ou plusieurs nœuds Cassandra. Keyspace : un conteneur d'espaces de clés au sein de Cassandra. Cluster : 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. Nœud 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 : Cassandra ne stocke pas les colonnes avec des valeurs nulles, ce qui permet d'économiser un espace de stockage important Quelle est la clé primaire dans Cassandra ? La identifie de manière unique chaque ligne d'une table. Dans Cassandra, la clé primaire comporte deux parties : clé primaire 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 . Cette clé primaire se compose de deux parties, représentées par les deux colonnes : PRIMARY KEY (city_id, event_id) 1. sert de clé de partition, ce qui signifie que les données seront partitionnées en fonction du champ , ce qui entraînera le stockage de toutes les lignes avec le même sur le même nœud. city_id city_id city_id 2. 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 event_id Les clés de clustering déterminent la disposition de stockage des données au sein d'un nœud. Il est possible d'avoir plusieurs clés de clustering, et toutes les colonnes répertoriées après la clé de partition sont appelées colonnes de clustering. Les colonnes de clustering définissent l'ordre dans lequel les données sont organisées sur un nœud. 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 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. un hachage cohérent Le 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 . 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. partitionneur clé de partition Nœud coordinateur Dans Cassandra, chaque nœud est conscient des attributions de jetons des autres nœuds via , 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 protocole Gossip Le nœud qui reçoit la demande est appelé 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. coordinateur 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. Chaque espace de clés dans Cassandra peut avoir un facteur de réplication différent. 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. Cette stratégie de réplication s'applique uniquement à un seul cluster de centre de données. 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. Lorsqu'il s'agit de configurations multi-centres de données, vous devez considérer la stratégie de topologie du réseau. Cette approche permet de spécifier différents facteurs de réplication pour chaque centre de données, permettant ainsi de contrôler le nombre de répliques à placer dans chaque emplacement spécifique. 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. : 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. Applications Internet des objets (IoT) 2. : 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. Données de séries chronologiques 3. : 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. Applications Web et mobiles 4. : 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. Analyse du Big Data en temps réel 5. : 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. Entrepôts de données distribués 6. : 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. Systèmes de messagerie 7. : 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. Systèmes de personnalisation et de gestion de contenu 8. : 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. Applications géographiquement distribuées 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 : 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. Projets à petite échelle : 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é. Systèmes transactionnels nécessitant des propriétés ACID : 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. Rejoindre des requêtes et des agrégations lourdes : 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. Données avec de fortes exigences de cohérence : 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. Lectures et écritures à faible latence dans un seul cluster : 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. Stockage Blob : 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. Applications nécessitant des requêtes 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. : 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. Evolution rapide du schéma : 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. Applications d'entrepôt de données qui impliquent des requêtes complexes, des jointures et une analyse de 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. Il y a plusieurs aspects intéressants de Cassandra que je couvrirai dans mon prochain article. pour ne pas le manquer ! Abonnez-vous à moi Acclamations!
