Quel est le but de Cassandra journal de validation?

S'il vous plaît quelques une de clarifier pour moi de comprendre, Journal de validation et de son utilisation.

Cassandra, lors de l'écriture sur le Disque est le journal de validation le premier point d'entrée ou MemTables.

Si Memtables est ce qui est arriver vidé sur le disque, qu'est-ce que l'utilisation de Commettre un journal, c'est le seul but de commettre journal du serveur de problèmes de synchronisation, si un nœud de données est en panne?

InformationsquelleAutor Satheesh | 2016-01-04

cassandra

59

Vous pouvez penser à la journal de validation que de l'optimisation, mais Cassandra serait unusably lent sans elle. Lorsque MemTables être écrites sur le disque, nous les appelons SSTables. SSTables sont immuables, sens une fois que Cassandra écrit sur le disque, il n'a pas les mettre à jour. Alors, quand une colonne de changements Cassandra a besoin d'écrire une nouvelle SSTable sur le disque. Si Cassandra a écrit ces SSTables sur le disque à chaque mise à jour il serait complètement IO lié et très lent.

Donc Cassandra utilise quelques astuces pour obtenir de meilleures performances. Au lieu d'écrire SSTables sur le disque à chaque mise à jour de colonne, il garde les mises à jour dans la mémoire et les bouffées de chaleur de ces changements sur le disque régulièrement afin de maintenir l'OI à un niveau raisonnable. Mais cela conduit au problème évident que si la machine tombe en panne ou que Cassandra se bloque vous perdez les données de ce nœud. Pour éviter de perdre des données, en plus de garder les changements récents dans la mémoire, Cassandra écrit les modifications dans ses CommitLog.

Vous pouvez vous demander pourquoi est écrit à la CommitLog mieux que d'écrire le SSTables. Le CommitLog est optimisé pour l'écriture. Contrairement à SSTables qui stockent les lignes dans l'ordre de tri, le CommitLog stocke les mises à jour dans l'ordre où elles ont été traitées par Cassandra. Le CommitLog stocke également des changements pour toutes les familles de la colonne dans un fichier unique, de sorte que le disque n'a pas besoin de faire un tas de cherche lorsqu'il reçoit des mises à jour de plusieurs familles de la colonne en même temps.

Essentiellement d'écriture des CommitLog sur le disque est mieux parce qu'il a d'écrire moins de données que l'écriture SSTables ne et il écrit toutes les données à un seul endroit sur le disque.

Cassandra conserve la trace des données a été vidées de SSTables et est en mesure de tronquer le journal de validation une fois que toutes les données de plus d'un certain point, a été écrite.

Lorsque Cassandra démarre il y a qu'à lire le journal de validation de retour à partir de ce dernier bon point dans le temps (le moment où nous savons que toutes les précédentes écritures ont été écrites dans un SSTable). Il ré-applique les changements dans le journal des modifications à son MemTables sorte qu'il peut obtenir dans le même état quand il s'est arrêté. Ce processus peut être lent, donc si vous êtes à l'arrêt d'un nœud Cassandra pour l'entretien c'est une bonne idée d'utiliser nodetool drain avant l'arrêt qui va vider dans la MemTables à SSTables et de faire la somme de travail sur le démarrage d'une beaucoup plus petite.
- Quelle est la différence si j'utilise nodetool flush au lieu de nodetool de vidange lors de l'arrêt du nœud?
- nodetool flush juste bouffées de chaleur memtables sur le disque. nodetool drain bouffées de chaleur memtables et aussi cesse d'accepter les connexions des clients et d'autres nœuds.
- Est le journal de validation de réplication? Sinon journaux sont point de défaillance unique, à droite?
InformationsquelleAutor psanford
29

L'écriture chemin de cassandra, fonctionne comme ceci:
```
Cassandra Node ---->Commitlog-----------------> Memtable
                         |                       |
                         |                       |
                         |---> Periodically      |---> Periodically
                              sync to  disk          flush to SSTable
```
Memtable et CommitLog sont PAS écrit (genre de) en parallèle. Écrire à CommitLog doit être terminé avant de commencer à écrire à Memtable. Code source de la pile est:
```
org.apache.cassandra.service.StorageProxy.mutateMV:mutation.apply->
org.apache.cassandra.db.Mutation.apply:Keyspace.open(keyspaceName).apply->
org.apache.cassandra.db.Keyspace.apply->
org.apache.cassandra.db.Keyspace.applyInternal{
    Tracing.trace("Appending to commitlog");
    commitLogPosition = CommitLog.instance.add(mutation)
    ...
    Tracing.trace("Adding to {} memtable",...
    ...
    upd.metadata().name(...);
    ...
    cfs.apply(...);
    ...
}
```
Le but de la commitlog est d'être en mesure de recréer le memtable après un nœud en panne ou redémarré. Ceci est important, car la memtable obtient seulement vidé sur le disque quand il est "pleine" - dans le sens de l'configuré memtable taille est exceded - ou de la chasse d'eau est effectuée par nodetool ou opscenter. Ainsi, les données dans memtable n'est pas conservée directement.

Cela dit, une bonne chose avant le redémarrage d'un nœud est d'appeler "nodetool flush" pour vous assurer que votre memtable sont conservées. Cela permet également de réduire le temps de lecture de la commitlog après le nœud se lève de nouveau.
- Est le journal de validation de réplication? Sinon journaux sont point de défaillance unique, à droite?
- Chaque nœud dispose de son propre journal de validation. Il n'est pas un point de défaillance unique.
- Est l'accusé de réception au client après commitlog et memtable sont mis à jour? Si oui, alors pourquoi ne pas faire les deux en parallèle?
InformationsquelleAutor HashtagMarkus

Vous devez vous connecter pour publier un commentaire.