Matthieu
Nantern
Cassandra internals
#XebiConFr
@mNantern
1
#XebiConFr
$ whoami
2
#XebiConFr
1. Je suis présent dans tous les
projets informatiques
2. Bien souvent on ne me
comprend pas
3. Je limite dès q...
#XebiConFr4
#XebiConFr
• Se base sur Google BigTable et
Amazon Dynamo
• 2008 : libération par Facebook
• 2010 : Top Level Project Apac...
#XebiConFr
• Écrire des données
• Lire des données
• Passer à l'échelle
• Survivre
Sommaire
6
#XebiConFr
Écrire des données
7
#XebiConFr
1. Pour écrire vite, écrivons en
mémoire !
2. Une table classique avec
index
3. Que se passe-t-il si la machine...
#XebiConFr
• Append only file
• Rapide et persistant !
• Permet de rejouer les requêtes
en cas de coupure brutale
Commit Lo...
#XebiConFr
• La mémoire c'est bien mais pas pour des
To de données
• Il faut parfois écrire sur le disque : Flush !
• Chaq...
#XebiConFr
• Trois structures sont écrites en même
temps que la SSTable :
• Index
• Résumé partition
• BloomFilter
On prép...
#XebiConFr
• Imaginons une table mise à
jour fréquemment…
• SSTable
• SSTable everywhere !
• Compaction to the rescue
SSTa...
#XebiConFr
• Il est nécessaire de diminuer
régulièrement le nombre de
SSTable
• 10 ms pour faire un disk seek !
• Les supp...
#XebiConFr
1. Écrire dans le commit log
2. Écrire dans la memtable
3. Flusher sur disque
Write Path
14
#XebiConFr
1. Écrire uniquement de façon séquentielle
2. Ne pas laisser trainer ses affaires
3. Ne pas oublier la lecture
B...
#XebiConFr
Lire des données
16
#XebiConFr
• Une structure optionnelle en
mémoire qui stocke les
données lues récemment
• Solution la plus rapide, tout es...
#XebiConFr
Read Path
18
1
#XebiConFr
• Structure probabiliste en
mémoire
• Permet de dire si une donnée
pourrait être dans la SSTable
• Les faux pos...
#XebiConFr
Read Path
20
2
#XebiConFr
• Permet de garder en cache les
clés de partitions
• Optionnel
• Si la donnée est dans le cache
de clé, on pass...
#XebiConFr
Read Path
22
3
#XebiConFr
• En mémoire
• Permet d'indiquer la position
sur le disque de l'entrée que
l'on recherche dans l'index
• Stocke...
#XebiConFr
Read Path
24
4
#XebiConFr
• Premier appel sur le disque
• Permet de retrouver
l'emplacement des données de
notre clé de partitionnement
•...
#XebiConFr
Read Path
26
5
#XebiConFr
• En mémoire
• Par défaut, toutes les tables
sont compressées
• Permet de trouver les blocks
contenant les donn...
#XebiConFr
Read Path
28
6
#XebiConFr
• Finalement, on récupère la
donnée de la SSTable !
• On combine les données
provenant de toutes les
SSTables e...
#XebiConFr
On résume
30
6
5
4
3 2
1
#XebiConFr
On résume
31
#XebiConFr
1. Minimiser les lectures sur le disque
2. Pour cela garder en mémoire le maximum de choses
3. Faire confiance à...
#XebiConFr
Passer à l'échelle
33
#XebiConFr
3 mécanismes existent au cours
de la vie d'un cluster :
• Seed: configuration
• Gossip: peer to peer,
périodique...
#XebiConFr
• Masterless
• Coordinator
• Cohérence : ALL, QUORUM,
ONE
• Attention à la surcharge
réseau !
Se partager le tr...
#XebiConFr
• Partitionnement
• RÉplication des données
• Hinted handoff
Se partager les données
36
#XebiConFr
• Dédié à la lecture
• Si un noeud est trop lent à
répondre, la requête est
transmise à un autre noeud qui
déti...
#XebiConFr
• Le problème
• La solution : LightWeight
Transaction
• Comment ? Paxos !
Se mettre d'accord
38
Process 1 Proce...
#XebiConFr
Paxos Cassandra (1/4)
39
#XebiConFr
Paxos Cassandra (2/4)
40
#XebiConFr
Paxos Cassandra (3/4)
41
#XebiConFr
Paxos Cassandra (4/4)
42
#XebiConFr
Démo
43
#XebiConFr
1. Pas de master => Pas de SPOF
2. Répartir la donnée sur certains noeuds
3. Il est possible de se mettre d'acc...
#XebiConFr
Survivre
45
#XebiConFr
• La perte d'un serveur est un
phénomène normal
• Une seule solution : répliquer
la donnée
• Il faut le tester ...
#XebiConFr
• Se configure simplement dans
un fichier texte
• Cassandra s'arrange pour
stocker les données dans des
racks diff...
#XebiConFr
• Natif dans Cassandra, à
déclarer lors de la création du
keyspace :
Perte d'un datacenter
CREATE KEYSPACE "Exc...
#XebiConFr
Démo !
49
#XebiConFr
1. Répliquer ses données sur différents serveurs
2. Dans différents racks
3. Dans différents datacenter
4. Sur diff...
#XebiConFr
Conclusion
51
#XebiConFr
• Des caractéristiques
impressionnantes !
• Compliquée à utiliser au
quotidien, Paradigm Shift
• Choisir la bon...
#XebiConFr
Questions ?
53
#XebiConFr
Merci !
54
Prochain SlideShare
Chargement dans…5
×

XebiConFr 15 - À la découverte des mécanismes internes de Cassandra

606 vues

Publié le

Construire une base de données distribuée, scalable et hautement disponible est une opération extrêmement complexe.

Dans cette présentation, nous allons voir en détail certains des mécanismes utilisés pour le fonctionnement interne de Cassandra, l'une des bases NoSQL les plus populaires actuellement. Au programme de cette session : Comment les informations sont répliquées dans un cluster, comment sont réalisées les écritures et les lectures et comment Cassandra arrive à les garder (relativement) rapides. Enfin nous verrons comment les machines d'un cluster parviennent à se mettre d'accord à l'aide d'un algorithme distribué nommé Paxos.

Par Matthieu Nantern, Consultant chez Xebia

La vidéo de la conférence est à retrouver sur : http://www.xebicon.fr/programme.html

Publié dans : Logiciels
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
606
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

XebiConFr 15 - À la découverte des mécanismes internes de Cassandra

  1. 1. Matthieu Nantern Cassandra internals #XebiConFr @mNantern 1
  2. 2. #XebiConFr $ whoami 2
  3. 3. #XebiConFr 1. Je suis présent dans tous les projets informatiques 2. Bien souvent on ne me comprend pas 3. Je limite dès qu'il s'agit de scaler Qui suis-je ? 3
  4. 4. #XebiConFr4
  5. 5. #XebiConFr • Se base sur Google BigTable et Amazon Dynamo • 2008 : libération par Facebook • 2010 : Top Level Project Apache • Octobre 2011 : version 1.0 • Septembre 2013 : version 2.0 • Version 3 en bêta Cassandra 5
  6. 6. #XebiConFr • Écrire des données • Lire des données • Passer à l'échelle • Survivre Sommaire 6
  7. 7. #XebiConFr Écrire des données 7
  8. 8. #XebiConFr 1. Pour écrire vite, écrivons en mémoire ! 2. Une table classique avec index 3. Que se passe-t-il si la machine a un problème ? Memtable 8
  9. 9. #XebiConFr • Append only file • Rapide et persistant ! • Permet de rejouer les requêtes en cas de coupure brutale Commit Log 9
  10. 10. #XebiConFr • La mémoire c'est bien mais pas pour des To de données • Il faut parfois écrire sur le disque : Flush ! • Chaque Memtable est écrit en une fois sur le disque et ne bouge plus => Immutable • Libère la mémoire et supprime le commit log SSTable 10
  11. 11. #XebiConFr • Trois structures sont écrites en même temps que la SSTable : • Index • Résumé partition • BloomFilter On prépare la lecture 11
  12. 12. #XebiConFr • Imaginons une table mise à jour fréquemment… • SSTable • SSTable everywhere ! • Compaction to the rescue SSTable everywhere! 12
  13. 13. #XebiConFr • Il est nécessaire de diminuer régulièrement le nombre de SSTable • 10 ms pour faire un disk seek ! • Les suppressions Compaction 13
  14. 14. #XebiConFr 1. Écrire dans le commit log 2. Écrire dans la memtable 3. Flusher sur disque Write Path 14
  15. 15. #XebiConFr 1. Écrire uniquement de façon séquentielle 2. Ne pas laisser trainer ses affaires 3. Ne pas oublier la lecture Bilan : écrire vite 15
  16. 16. #XebiConFr Lire des données 16
  17. 17. #XebiConFr • Une structure optionnelle en mémoire qui stocke les données lues récemment • Solution la plus rapide, tout est en mémoire • La mémoire est limitée, contient peu d'éléments Row cache 17
  18. 18. #XebiConFr Read Path 18 1
  19. 19. #XebiConFr • Structure probabiliste en mémoire • Permet de dire si une donnée pourrait être dans la SSTable • Les faux positifs sont possibles pas les faux négatifs Bloom Filter 19
  20. 20. #XebiConFr Read Path 20 2
  21. 21. #XebiConFr • Permet de garder en cache les clés de partitions • Optionnel • Si la donnée est dans le cache de clé, on passe directement à l'étape "Compression offset" Key Cache 21
  22. 22. #XebiConFr Read Path 22 3
  23. 23. #XebiConFr • En mémoire • Permet d'indiquer la position sur le disque de l'entrée que l'on recherche dans l'index • Stocke 1/128 clés Partition summary 23
  24. 24. #XebiConFr Read Path 24 4
  25. 25. #XebiConFr • Premier appel sur le disque • Permet de retrouver l'emplacement des données de notre clé de partitionnement • Est ensuite ajouté au "Key Cache" Partition index 25
  26. 26. #XebiConFr Read Path 26 5
  27. 27. #XebiConFr • En mémoire • Par défaut, toutes les tables sont compressées • Permet de trouver les blocks contenant les données Compression offsets Map 27
  28. 28. #XebiConFr Read Path 28 6
  29. 29. #XebiConFr • Finalement, on récupère la donnée de la SSTable ! • On combine les données provenant de toutes les SSTables et de la Memtable en prenant la donnée la plus récente • On a notre donnée finale pour notre machine ! Lecture dans la SSTable 29
  30. 30. #XebiConFr On résume 30 6 5 4 3 2 1
  31. 31. #XebiConFr On résume 31
  32. 32. #XebiConFr 1. Minimiser les lectures sur le disque 2. Pour cela garder en mémoire le maximum de choses 3. Faire confiance à l'OS pour les SSTables et les index Bilan : lire vite 32
  33. 33. #XebiConFr Passer à l'échelle 33
  34. 34. #XebiConFr 3 mécanismes existent au cours de la vie d'un cluster : • Seed: configuration • Gossip: peer to peer, périodique et persisté • Failure detection: calcul de seuil en fonction de la performance réseau, de la charge et des performances Trouver ses amis 34
  35. 35. #XebiConFr • Masterless • Coordinator • Cohérence : ALL, QUORUM, ONE • Attention à la surcharge réseau ! Se partager le travail 35
  36. 36. #XebiConFr • Partitionnement • RÉplication des données • Hinted handoff Se partager les données 36
  37. 37. #XebiConFr • Dédié à la lecture • Si un noeud est trop lent à répondre, la requête est transmise à un autre noeud qui détient la donnée • Nécessite de répliquer la donnée Eager retry 37
  38. 38. #XebiConFr • Le problème • La solution : LightWeight Transaction • Comment ? Paxos ! Se mettre d'accord 38 Process 1 Process 2 Lecture Lecture => 0 => 0 Ecriture Ecriture
  39. 39. #XebiConFr Paxos Cassandra (1/4) 39
  40. 40. #XebiConFr Paxos Cassandra (2/4) 40
  41. 41. #XebiConFr Paxos Cassandra (3/4) 41
  42. 42. #XebiConFr Paxos Cassandra (4/4) 42
  43. 43. #XebiConFr Démo 43
  44. 44. #XebiConFr 1. Pas de master => Pas de SPOF 2. Répartir la donnée sur certains noeuds 3. Il est possible de se mettre d'accord mais ce n'est pas gratuit Bilan : Travailler en équipe 44
  45. 45. #XebiConFr Survivre 45
  46. 46. #XebiConFr • La perte d'un serveur est un phénomène normal • Une seule solution : répliquer la donnée • Il faut le tester => Chaos Monkey Perte d'un serveur 46
  47. 47. #XebiConFr • Se configure simplement dans un fichier texte • Cassandra s'arrange pour stocker les données dans des racks différents • Il faut avoir au moins 2 racks ! Perte d'un rack 47
  48. 48. #XebiConFr • Natif dans Cassandra, à déclarer lors de la création du keyspace : Perte d'un datacenter CREATE KEYSPACE "Excalibur" WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'dc1' : 3, 'dc2' : 2}; 48
  49. 49. #XebiConFr Démo ! 49
  50. 50. #XebiConFr 1. Répliquer ses données sur différents serveurs 2. Dans différents racks 3. Dans différents datacenter 4. Sur différentes planètes Bilan : Survivre 50
  51. 51. #XebiConFr Conclusion 51
  52. 52. #XebiConFr • Des caractéristiques impressionnantes ! • Compliquée à utiliser au quotidien, Paradigm Shift • Choisir la bonne base pour le bon usage Silver bullet ? 52
  53. 53. #XebiConFr Questions ? 53
  54. 54. #XebiConFr Merci ! 54

×