Cassandra - ordre de cohérence

Question

Je sais que dans Cassandra, il n'y a pas de cohérence forte sauf si vous le demandez explicitement (et même alors, il n'y a pas de transactions).

Cependant, je m'intéresse à l '"ordre" de la cohérence. Prenez l'exemple suivant:

Dans un noeud de base de données, il existe 3 noeuds (A, B et C). Deux requêtes d'insertion sont envoyées via la même connexion CQL (ou d'ailleurs, je ne pense pas que cela soit pertinent pour cette question). Les deux fonctionnent sur différents tableaux (cela pourrait être pertinent).

INSERT INTO table_a (id) VALUES (0) 
INSERT INTO table_b (id) VALUES (1) 

Directement après que les questions ont été exécutées avec succès sur le nœud auquel elles sont envoyées, elles tombent en panne. Le nœud peut ou non avoir réussi à propager ces deux requêtes à B et C.

Maintenant, je pense qu'il y a un ordre de cohérence. Les deux sont propogués et exécutés avec succès sur B et C, ou seulement la première requête est, ou les deux sont. Je pense que, en aucun cas seulement la requête deuxième est propogated et exécuté, et pas le premier (en raison de l'ordre des paquets tcp, et le fait que évidemment, tous les nœuds partagent la même stratégie de cohérence).

Ai-je raison?

Answer 1

Vous avez raison, au moins sur le noeud auquel vous vous connectez. Qu'est-ce qui se passe sur le serveur est, pour un niveau de cohérence UNE écriture:

1. Recevez insert TABLE_A
2. Ecrire dans commitlog
3. Acquitter écrire au client
4. Recevoir insert table_b
5. Ecrire dans commitlog
6. Reconnaissez écrire au client

Le La clé est qu'il existe un commitlog global. Donc, vous ne pouvez pas le vider pour une table et pas une autre. De plus, comme les écritures sont séquentielles, vous savez que l'écriture a été faite dans le commitlog avant de revenir.

Le commitlog est vidé périodiquement (par défaut), alors peut rincer après 2 mais avant 5, auquel cas seul l'insert table_a est maintenu en cas d'accident immédiatement après 4 ou 5.

sur Dans d'autres nœuds, l'ordre n'est pas garanti, car l'écriture est effectuée de manière asynchrone et les écritures sont multithread. Mais il n'est pas possible de perdre totalement la première écriture et pas la seconde si le nœud d'origine n'échoue pas définitivement.

Si vous voulez des garanties plus fortes, vous pouvez utiliser le traitement par lots de Cassandra.

Cassandra peut vous garantir qu'aucune des deux écritures ne réussira si vous les écrivez en tant que lot. Pour les anciennes versions de Cassandra, si les mises à jour d'un lot ont la même clé de ligne (clé de partition en langage CQL), même si elles sont dans des familles de colonnes différentes (tables), elles seront validées atomiquement au commitlog.

Nouveauté 1.2 est un journal de lots sur plusieurs lignes qui offre les mêmes garanties - tout le lot est appliqué ou aucun.