Cassandra

Mme Ines Slimene
Ines_slimene@yahoo.fr

Présentation
Base de données :
◦ Distribuée
◦ À haute performance
◦ Extrêmement évolutive
◦ Tolérante aux fautes (pas de SPOF)
Développé par Facebook en 2007 pour la messagerie interne.
En 2008, le projet est cédé à la fondation Apache et devient "top-level-project" à partir de 2010.
Cassandra est alors enrichie et de nouvelles fonctionnalités y sont ajoutées.
Cassandra est utilisée par NetFlix ou Cisco WebEx.
Cassandra reprend les concepts de 2 bases de données existantes :
◦ BigTable, créé par Google, pour son modèle de données orienté colonne et son mécanisme de persistance sur
disque
◦ Dynamo, créé par Amazon, pour son architecture distribuée sans nœud maître.
https://inesslimene.wixsite.com/moncours CASSANDRA 2

Architecture
Système distribué, P2P Composés de plusieurs nœuds identiques
(Pas de notion de master)
Les données sont partitionnées par défaut à travers les différents
nœuds du cluster
Les données sont répliquées pour assurer une tolérance aux fautes
maximale
Lecture et écriture à partir de n’importe quel nœud,
indépendamment de l’emplacement des données
Utilisation du protocole Gossip pour la communication entre les
différents nœuds du cluster
◦ Échange de données entre les nœuds chaque seconde
Cluster

Partitionnement
Les nœuds sont structurés selon une topologie en anneaux
Partitionnement facile des données à travers les différents nœuds participants du cluster
Chaque nœud est responsable d’une partie de la base de données
Les données sont insérées par l’utilisateur dans une famille de colonnes
Elles sont ensuite placées sur un nœud, selon sa clé de colonne
Stratégies de partitionnement
◦ Partitionnement aléatoire
◦ Par défaut, recommandé
◦ Données partitionnée le plus équitablement possible à travers les différents nœuds
◦ Partitionnement ordonné
◦ Sauvegarde les clés de familles de colonnes par ordre à travers les nœuds d’un cluster
◦ Peut provoquer des problèmes, surtout pour la répartition des charges (des nœuds avec des données plus volumineuses que d’autres)
Si la stratégie d’une base est modifiée, il faut recharger toutes les données

Réplication
Pour assurer la tolérance aux fautes et pas de SPOF, il est possible de créer une ou plusieurs
copie(s) de chaque colonne à travers les nœuds participants
L’utilisateur spécifie le facteur de réplication désiré à la création du keyspace (base de données)
Les données sont insérées par l’utilisateur dans une famille de colonnes
La colonne est répliquée dans les nœuds du cluster selon le facteur de réplication
Si un des nœuds est en panne lors d'une écriture, alors la donnée à écrire va être gardée en
mémoire dans une table spéciale du système, appelé hints.
Une fois que le nœud redevient accessible, alors toutes les données en mémoire vont être
écrites dans le nœud, et supprimées de la table hints.
La table hints est elle même distribuée entre tous les nœuds du cluster.

Stratégies de réplication
Stratégie Simple : SimpleStrategy
◦ Utilisé lorsqu’il n’y a qu’un data center.
◦ La colonne originelle est placée sur un nœud déterminé par le partitionneur
◦ Les répliques seront placées sur les nœuds suivants de l’anneau (sens des aiguilles d’une montre)
Stratégie par topologie du réseau : NetworkTopologyStrategy
◦ à utiliser lorsque le cluster est déployé sur plusieurs data-centers.
◦ Cette stratégie permet de spécifier le nombre de copies voulu dans chaque datacenter,
◦ elle permet également de placer les copies sur des racks distincts.
◦ Plus de contrôle sur l’emplacement des répliques de colonnes

Consistance
Écriture :
◦ Données écrites d’abord dans un commit log pour la durabilité
◦ Ensuite, écriture en mémoire dans une MemTable
◦ Une fois la MemTable pleine, les données sont sauvegardées dans le disque, dans une SSTable (Sorted Strings
Table)
Même si les transactions relationnelles (commit et rollback) ne sont pas supportées, les écritures sont
atomiques au niveau des colonnes (Soit toutes les colonnes sont modifiées, soit aucune ne l’est )
Cassandra est la base de données NOSQL la plus rapide en écriture

Consistance
Extension du concept de consistance éventuelle à une consistance ajustable
Choix possible entre une consistance forte ou éventuelle selon les besoins
Ce choix est fait par opération, ce n’est pas une stratégie globale pour la base de données
Exemple : pour changer la stratégie de lecture en quorum
◦ SELECT * FROM users USING CONSISTENCY QUORUM WHERE state=‘TX’;
Consistance gérée à travers plusieurs datacenters

Consistance : Stratégies d’Écriture
Nombre de répliques qui doivent être écrites avec succès avant de retourner un acquittement
au client :
Any une écriture doit réussir sur n’importe quel nœud, au moins un. Offre la plus haute
disponibilité, mais la plus basse consistance
One (défaut) une écriture doit réussir sur le commit log et la memtable d’au moins une réplique
Quorum une écriture doit réussir sur un certain pourcentage de répliques (pourcentage =
(facteur de réplication/2)+1)
Meilleure alternative en terme de consistance et de disponibilité
Local-Quorum une écriture doit réussir sur un certain pourcentage de nœuds répliques sur le
même rack que le nœud coordinateur
Each-Quorum une écriture doit réussir sur un certain pourcentage de nœuds répliques sur tous les
racks.
All une écriture doit réussir sur tous les nœuds répliques d’une colonne. Offre la plus
haute consistance, mais la plus basse disponibilité

Stratégies de Lecture : Read Repair
Il y a trois types de requêtes de lecture que le coordinateur peut envoyer aux réplicas : Direct
request, Digest request et Read repair request.
◦ Pour un direct read request, le coordinateur contacte un seul réplica.
◦ Ensuite, le coordinateur envoie un digest request au nombre de réplicas spécifié par le niveau de
cohérence et vérifie que les données sont mises à jour.
◦ Finalement, le coordinateur envoie un digest request à tous les réplicas restants.
◦ Si l’un des nœuds n’est pas à jour, un background read repair request sera envoyé.
Cassandra assure que les données fréquemment lues soient consistantes
À la lecture d’une donnée, le nœud coordinateur compare toutes ses répliques en arrière plan,
Si ces données ne sont pas consistantes, envoie une demande d’écriture aux nœuds réplicas
pour mettre à jour leur donnée et afficher la donnée la plus récente
Read Repair peut être configuré par famille de colonnes et est activé par défaut.

Gestion des Données et Objets
Deux interfaces pour gérer les objets/données
◦ Cassandra CLI (Command Line Interface)
◦ CQL (Cassandra Query Language)
CLI : Interface originelle conçue pour créer des objets, entrées et manipuler les données
CQL : Utilisée pour créer/manipuler des données en utilisant un langage proche de SQL

Vocabulaire
◦ Keyspace (équivalent de database )
◦ Column Family (équivalent de table )
◦ Dans la nouvelle version du langage CQL, appelée Table
◦ Schéma plus flexible et dynamique qu’une table
◦ Colonne (équivalent à enregistrement )
◦ Indexée par une clef
◦ D’autres champs peuvent être également indexés, mais à la demande

Modélisation : Relation one to many
Un instrument a plusieurs catégories
Les jointures n'étant pas possible, on dénormalise la relation.

Modélisation : Relation many to many
Un utilisateurs peux commenter plusieurs livre, et un livre peut être commenté par plusieurs
utilisateurs.
On est obligé de dénormaliser et de faire deux tables.

Modélisation : Exemple
Soit le diagramme de classe suivant :
Traduire ce diagramme en une base de données orientée colonne, sachant que l'objectif de
l'application est de :
◦ Lister les factures d’un client du plus récent au plus ancien. Seul un résumé de la facture devra être
affiché.
◦ Charger le détail d’une facture à partir de l’identifiant de facture trouvé grâce à la première requête.

Gestion des Données et Objets : CQL
Objets tels que les keyspaces, familles de colonnes et index sont créés, modifiés et supprimés
avec les requêtes usuelles: CREATE, ALTER et DROP
Données insérées, modifiées et supprimées avec INSERT, UPDATE et DELETE
Données lues avec SELECT
Mais
◦ Ne supporte pas des opérations telles que GROUP BY(fonctions d’agrégation ), JOIN, ORDER BY (sauf
pour les clefs composées, et ordonnées seulement selon la deuxième clef primaire)…
◦ Pas de filtres sur les colonnes sans la création d’un index.

CQL : les types de données

CQL : les Collections
CQL3 supporte les collections pour stocker des structures de données complexes.
• Set {value,…}
• List [value,…]
• Map {key:value,…}
cqlsh> CREATE TABLE sample(id int PRIMARY KEY,
string_set set<text>,
string_list list<text>,
string_map map<text, text>);
cqlsh> INSERT INTO sample (id, string_set, string_list, string_map)
VALUES (1,
{'text1','text2','text1'},
['text1','text2','text1'],
{'key1':'value1’});
cqlsh> SELECT * FROM sample;
id | string_list | string_map | string_set
----+-----------------------------+--------------------+--------------------
1 | ['text1', 'text2', 'text1'] | {'key1': 'value1'} | {'text1', 'text2'}
(1 rows)

Cassandra

Contenu connexe

Tendances (20)

Similaire à Cassandra (20)

Plus de Ines Slimene (13)

Dernier (20)

Cassandra