Comment cassandra trouve-t-il le nœud qui contient les données?
J'ai lu pas mal d'articles et beaucoup de questions/réponses sur SO about Cassandra mais je n'arrive toujours pas à comprendre comment Cassandra décide à quel (s) nœud (s) aller quand il lit les données.
Tout d'abord, quelques hypothèses sur un cluster imaginaire:
- Stratégie de réplication = simple
- Utilisation du partitionneur aléatoire
- Cluster de 10 nœuds
- Facteur de réplication de 5
Voici ma compréhension du fonctionnement des écritures en fonction de divers articles Datastax et d'autres articles de blog que j'ai lus:
- Le client envoie les données à un nœud aléatoire
- Le nœud "aléatoire" est décidé sur la base du hachage MD5 de la clé primaire.
Les données sont écrites dans commit_log et memtable, puis propagées 4 fois (avec RF = 5).
Les 4 nœuds suivants de l'anneau sont ensuite sélectionnés et les données y sont conservées.
Jusqu'ici tout va bien.
Maintenant, la question est, lorsque le client envoie une demande de lecture (disons avec CL = 3) au cluster, comment Cassandra sait-il quels nœuds (5 sur 10 comme le pire des cas)) doit contacter pour obtenir ces données? Sûrement, cela ne va pas aux 10 nœuds car cela serait inefficace.
Ai-je raison de supposer que Cassandra le fera à nouveau, fera un hachage MD5 de la clé primaire (de la demande) et choisira le nœud en fonction de cela, puis parcourra l'anneau?
En outre, comment fonctionne le cas de topologie de réseau? si j'ai plusieurs centres de données, comment Cassandra sait-il quels nœuds dans chaque DC/Rack contiennent les données? D'après ce que je comprends, seul le premier nœud est évident (puisque le hachage de la clé primaire a entraîné explicitement ce nœud).
Désolé si la question n'est pas très claire et veuillez ajouter un commentaire si vous avez besoin de plus de détails sur ma question.
Merci beaucoup,
Le client envoie les données à un nœud aléatoire
Cela peut sembler ainsi, mais il existe en fait une manière non aléatoire que votre pilote choisit un nœud pour parler. Ce nœud est appelé "nœud coordinateur" et est généralement choisi en fonction de la distance de réseau la plus petite (la plus proche). Les demandes des clients peuvent vraiment être envoyées à n'importe quel nœud, et au début, elles seront envoyées aux nœuds connus de votre pilote. Mais une fois qu'il se connecte et comprend la topologie de votre cluster, il peut devenir un coordinateur "plus proche".
Les nœuds de votre cluster échangent des informations de topologie entre eux à l'aide du Gossip Protocol . Le potin s'exécute toutes les secondes et garantit que tous les nœuds sont tenus à jour avec les données de Snitch que vous avez configuré. Le vif permet de savoir à quels centres de données et racks appartient chaque nœud.
De cette manière, le nœud coordinateur dispose également de données sur les nœuds responsables de chaque plage de jetons. Vous pouvez voir ces informations en exécutant un nodetool ring depuis la ligne de commande. Bien que si vous utilisez des nœuds virtuels, cela sera plus difficile à vérifier, car les données sur les 256 nœuds virtuels (par défaut) clignoteront rapidement à l'écran.
Disons donc que j'ai une table que j'utilise pour suivre les membres d'équipage du navire par leur prénom, et supposons que je veux rechercher Malcolm Reynolds. Exécution de cette requête:
SELECT token(firstname),firstname, id, lastname
FROM usersbyfirstname WHERE firstname='Mal';
... renvoie cette ligne:
token(firstname) | firstname | id | lastname
----------------------+-----------+----+-----------
4016264465811926804 | Mal | 2 | Reynolds
En exécutant un nodetool ring Je peux voir quel nœud est responsable de ce jeton:
192.168.1.22 rack1 Up Normal 348.31 KB 3976595151390728557
192.168.1.22 rack1 Up Normal 348.31 KB 4142666302960897745
Ou encore plus simple, je peux utiliser nodetool getendpoints pour voir ces données:
$ nodetool getendpoints stackoverflow usersbyfirstname Mal
Picked up Java_TOOL_OPTIONS: -javaagent:/usr/share/Java/jayatanaag.jar
192.168.1.22
Pour plus d'informations, consultez certains des éléments liés ci-dessus ou essayez d'exécuter nodetool gossipinfo.
Cassandra utilise un hachage cohérent pour mapper chaque clé de partition à une valeur de jeton. Chaque nœud possède des plages de valeurs de jeton comme plage principale, de sorte que chaque valeur de hachage possible soit mappée sur un nœud. Les répliques supplémentaires sont ensuite conservées de manière systématique (comme le nœud suivant dans l'anneau) et stockées dans les nœuds comme leur plage secondaire.
Chaque nœud du cluster connaît la topologie de l'ensemble du cluster, par exemple les nœuds dans quel centre de données, leur emplacement dans l'anneau et les plages de jetons dont chaque nœud est propriétaire. Les nœuds obtiennent et conservent ces informations à l'aide du protocole Gossip.
Lorsqu'une demande de lecture arrive, le nœud contacté devient le coordinateur de la lecture. Il calculera quels nœuds ont des répliques pour la partition demandée, puis choisira le nombre de nœuds requis pour atteindre le niveau de cohérence. Il enverra ensuite des demandes à ces nœuds et attendra leurs réponses et fusionnera les résultats en fonction des horodatages de colonne avant de renvoyer le résultat au client.
Cassandra localisera toutes les données basées sur un clé de partition qui est mappé à une valeur de jeton par le partitionneur. Les jetons font partie d'une plage de valeurs finie anneau de jeton où chaque partie de l'anneau appartient à un nœud du cluster. Le nœud propriétaire de la plage d'un certain jeton est dit être le principal de ce jeton. Les répliques seront sélectionnées par la stratégie de réplication des données. Fondamentalement, cela fonctionne en allant dans le sens des aiguilles d'une montre dans l'anneau à jetons, en commençant par le principal et en s'arrêtant en fonction du nombre de répliques requises.
Ce qui est important à réaliser, c'est que chaque nœud du cluster est capable d'identifier les nœuds responsables d'une certaine clé en fonction de la logique décrite ci-dessus. Chaque fois qu'une valeur est écrite dans le cluster, le nœud acceptant la demande (le nœud coordinateur) connaît immédiatement les nœuds qui doivent exécuter l'écriture.
Dans le cas de plusieurs centres de données, toutes les clés seront mappées sur tous les contrôleurs de domaine au même jeton déterminé par le partitionneur. Cassandra essaiera d'écrire sur chacun DC et les répliques de chaque DC.