Une introduction aux principes et techniques mises en œuvre avec la base de données distribuée Cassandra.

1. www.cetic.be
Se noyer dans les yeux de Cassandre
1
Mathieu Goeminne

2. www.cetic.be
Au programme
• AP over C
• Les fondations
• Modèle de donnée et fonctionnalités
• Stockage de la donnée
• Réplication et cohérence
• Topologie des nœuds
• Quelques cas d’utilisation
2

3. www.cetic.be
AP over C
3

4. www.cetic.be
AP over C
• Propriétés CAP
• Consistency: une donnée n’a qu’un seul état visible.
• Availability: Tant que le système tourne, la donnée est
disponible.
• Partition Tolerance: Quel que soit le nombre de serveurs, toute
requête doit fournir un résultat correct.
• Théorème CAP
• Dans toute BDD distribuée, on ne peut avoir que 2 de ces 3
propriétés.
• En réalité, on est plus sur un continuum.
4

5. www.cetic.be
AP over C
5

6. www.cetic.be
Les fondations
6

7. www.cetic.be
Les fondations: Dynamo
• Projet d’Amazon (2004) pour un stockage distribué et décentralisé à
grande échelle.
• Tous les nœuds ont les mêmes responsabilités, pas de nœud
spécial pour la maîtrise ou servant de point d’entrée.
• Capacités de stockage et de traitement augmentées linéairement
par l’ajout de nœuds.
• À mi-chemin entre les bases de données et les tables de hashage
distribuées (DHTs): Réseau P2P
• Résilience aux défaillances: détection de différences entre les nœuds
par un arbre de Merkle.
• Gestion du cluster par un protocole Gossip: les nœuds en contact
s’échangent des « rumeurs » sur la disponibilité des autres nœuds.
• AWS DynamoDB est inspiré de ce projet, mais repose sur un nœud
maître.
7

8. www.cetic.be
Les fondations: Dynamo
• Projet d’Amazon (2004) pour un stockage distribué et décentralisé à
grande échelle.
• Tous les nœuds ont les mêmes responsabilités, pas de nœud
spécial pour la maîtrise ou servant de point d’entrée.
• Capacités de stockage et de traitement augmentées linéairement
par l’ajout de nœuds.
• À mi-chemin entre les bases de données et les tables de hashage
distribuées (DHTs): Réseau P2P
• Résilience aux défaillances: détection de différences entre les nœuds
par un arbre de Merkle.
• Gestion du cluster par un protocole Gossip: les nœuds en contact
s’échangent des « rumeurs » sur la disponibilité des autres nœuds.
• AWS DynamoDB est inspiré de ce projet, mais repose sur un nœud
maître.
7
?
?
?

9. www.cetic.be
Les fondations: Big Table
• Projet de Google (2014) pour une base de données distribuée
orientée « wide column store »
• [String, String, Timestamp] -> ByteArray
• Les tables sont divisées en tablets, sur base des clefs de colonnes.
1 tablet ~= 100 Mo => Distribution => Passage à l’échelle.
• Chez Google, repose sur GoogleFS (système de fichier distribué)
• A inspiré HBase, Hypertable et Cassandra.
8

10. www.cetic.be
Modèle de donnée et fonctionnalités
9

11. www.cetic.be
Modèle de donnée et fonctionnalités
• Tables de type Map[K1, SortedMap[K2, V]]
• Dictionnaire de dictionnaires (ordonnés) de valeurs.
• Coutisse/085 => Mme Hedwige => {42, Rue des Éléphants; 085/44.47.19}
• Pour accéder à la donnée, connaître K1 est obligatoire.
• Connaître K2 est théoriquement facultatif, mais en pratique nécessaire point
de vue perf.
• Besoin d’organiser les données en fonction des requêtes à venir
• Plusieurs organisations de la même donnée
• Vues matérialisées possibles
• Pas de clef étrangère, de contraintes sur les données.
• ~ Pas d’autres index.
• Pas de jointures (trop onéreuses dans un environnement distribué)
• Dénormalisation privilégiée (⚠ risque pour l’intégrité)
10

12. www.cetic.be
Modèle de donnée et fonctionnalités
11

13. www.cetic.be
Modèle de donnée et fonctionnalités
11
Clef primaire composée.
tag=clef de partition (de ligne)
time=clef de clustering
Pour chaque tag, les times sont
ordonnés.

14. www.cetic.be
Modèle de donnée et fonctionnalités
11
Clef primaire composée.
tag=clef de partition (de ligne)
time=clef de clustering
Pour chaque tag, les times sont
ordonnés.
tag time value quality
sensor1 t1 v1 q1
sensor1 t2 v2 q2
sensor2 t3 v3 q3
sensor2 t4 v4 q4
sensor1 t1 t2
value v1 value v2
quality q1 quality q2
sensor2 t3 t4
value v3 value v3
quality q3 quality q4
Ce qu’on voit Ce qui est stocké

15. www.cetic.be
Stockage de la donnée
12

16. www.cetic.be
Stockage de la donnée
13

17. www.cetic.be
Stockage de la donnée
13
Pour la durabilité.
Tri par ordre
d’arrivée

18. www.cetic.be
Stockage de la donnée
13
Pour la durabilité.
Tri par ordre
d’arrivée
Cache rapide.
Organisé par K1/K2

19. www.cetic.be
Stockage de la donnée
13
Pour la durabilité.
Tri par ordre
d’arrivée
Cache rapide.
Organisé par K1/K2
Immuables.
Log-structured merge (LSM) tree: indexation
rapide et pas chère.
Compaction: fusion de SStables

20. www.cetic.be
Réplication et cohérence
14

21. www.cetic.be
Réplication
• Chaque partition est dupliquée sur un nombre paramétrable de nœuds (RF =
Replication Factor).
• Si plusieurs DC, on peut spécifier un RF par DC.
• Typiquement RF=3, 5, …
• Affectation sur base de la clef de partition
• Les nœuds s’échangent des logs d’activité pour rester synchronisés
• La donnée survit à la défaillance de RF-1 nœuds.
• Répartition de charge
• Si le nombre de nœuds > RF, les nœuds se répartissent les partitions.
Passage à l’échelle.
• Normalement, RF nœuds peuvent répondre à une requête donnée.
15

22. www.cetic.be
Cohérence
• « Eventually Consistent »: Une donnée finit par n’avoir qu’un état.
Mais ça peut prendre du temps.
• On peut choisir le nombre de réplicats « confirmés » (CL) avant de
considérer un accès comme un succès: compromis C vs A
paramétrable par le client.
• ONE, QUORUM, ALL
• CL(W) + CL(R) > RF nécessaire pour garantir la cohérence à tout
moment.
16

23. www.cetic.be
CL et Disponibilité - Pourquoi un RF impair?
17
Nombre de nœuds à
atteindre
Disponibilité malgré la perte
de X nœuds (au moins)
RF ONE QUORUM ALL ONE QUORUM ALL
1 1 1 1 0 0 0
2 1 2 2 1 0 0
3 1 2 3 2 1 0
4 1 3 4 3 1 0
5 1 3 5 4 2 0
6 1 4 6 5 2 0
7 1 4 7 6 3 0
8 1 5 8 7 3 0

24. www.cetic.be
Topologie des nœuds
18

25. www.cetic.be
Topologie des nœuds
• L’espace de K1 est
composé de 264 (cst)
entrées.
• Entrées réparties
entre N (cst) nœuds
virtuels.
• VNodes pris en
charge par k
(dynamique) nœuds
« réels ».
19
264-1
264 / 4
264 / 2

26. www.cetic.be
Nœuds, Racks et Data Centers
20
• Nœud Rack Data
Center.
• C* tente de placer les
réplicats sur des racks et
des DC différents.
• Réplication asynchrone
automatique
∈ ∈

27. www.cetic.be
Quelques cas d'utilisation
21

28. www.cetic.be
Situation idéale pour Cassandra
• 0 downtime.
• Besoin de distribution pour l’effort et le stockage.
• BDD multi-site.
• Écriture massive, délai avant impact sur la lecture acceptable.
• Donnée rarement mise à jour.
• Accès à partir d’une clef primaire.
• Pas besoin de jointure ou d’agrégation.
22

29. www.cetic.be
Quelques cas d’utilisation
• Séries chronologiques, IoT, télémétrie
• Fonctionnalités TS à implémenter dans le client
• Mais le modèle de donnée s’y prête très bien
• Map[Capteur, SortedMap[Timestamp, Valeur]]
• Ex: Datadog (télémétrie d’infrastructure), Netflix (actions des utilisateurs),
TSorage
• Chat
• Map[Salon, SortedMap[Timestamp, Message]]
• Ex: Facebook Messenger (remplacé depuis)
• Suivi de status (Achats, colis, health tracker, …)
• Map[Item, SortedMap[EventID, Status]]
• Ex: Zalando (paniers d’achat, achats proprement dits)
23

30. www.cetic.be
Pour aller plus loin
24