XebiConFr 15 - À la découverte des mécanismes internes de Cassandra
•
1 j'aime•880 vues
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
Recommandé
Contenu connexe
Tendances
En vedette
En vedette (20)
Similaire à XebiConFr 15 - À la découverte des mécanismes internes de Cassandra
Similaire à XebiConFr 15 - À la découverte des mécanismes internes de Cassandra (20)
Plus de Publicis Sapient Engineering
Plus de Publicis Sapient Engineering (20)
XebiConFr 15 - À la découverte des mécanismes internes de Cassandra
- 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. #XebiConFr4
- 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. #XebiConFr • Écrire des données • Lire des données • Passer à l'échelle • Survivre Sommaire 6
- 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. #XebiConFr • Append only file • Rapide et persistant ! • Permet de rejouer les requêtes en cas de coupure brutale Commit Log 9
- 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. #XebiConFr • Trois structures sont écrites en même temps que la SSTable : • Index • Résumé partition • BloomFilter On prépare la lecture 11
- 12. #XebiConFr • Imaginons une table mise à jour fréquemment… • SSTable • SSTable everywhere ! • Compaction to the rescue SSTable everywhere! 12
- 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. #XebiConFr 1. Écrire dans le commit log 2. Écrire dans la memtable 3. Flusher sur disque Write Path 14
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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. #XebiConFr • Masterless • Coordinator • Cohérence : ALL, QUORUM, ONE • Attention à la surcharge réseau ! Se partager le travail 35
- 36. #XebiConFr • Partitionnement • RÉplication des données • Hinted handoff Se partager les données 36
- 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. #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
- 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
- 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. #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. #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
- 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
- 52. #XebiConFr • Des caractéristiques impressionnantes ! • Compliquée à utiliser au quotidien, Paradigm Shift • Choisir la bonne base pour le bon usage Silver bullet ? 52