Est-ce que les insertions Cassandra différant uniquement dans une clé de cluster génèrent des pierres tombales?

Question

Comment la gestion des mises à jour et des clés de cluster par Cassandra interagit-elle?

• Cassandra met à jour jamais vraiment dossiers une fois écrit, il marque l'ancienne version comme supprimé à l'aide d'une pierre tombale et enregistre à la fois l'ancienne et la nouvelle version, jusqu'à ce que l'ancienne version est finalement supprimée par un processus d'entretien: une forme de collecte des ordures.
• Les clés de cluster sont implémentées en utilisant un peu de magie qui enregistre les données dans un enregistrement "réel" qui a une seule clé de partition.

Il me semble que ces deux fonctionnalités pourraient interagir mal, provoquant la génération de déchets excessifs.

Considérez ce schéma:

CREATE TABLE t (
    p int, 
    c int, 
    d string, 
    PRIMARY KEY ((p), c), 
); 

Après l'exécution des insertions suivantes:

INSERT INTO t (p, c, d) VALUE (1, 1, "text-1"); 
INSERT INTO t (p, c, d) VALUE (1, 2, "text-2"); 

est là tenant à la fois la (1, 1, "text-1") et (1, 2, "text-2") un record de pierre tombale marquée contenant les données (1, 1, "text-1") et un nouveau record Les données? Autrement dit, la deuxième insertion a-t-elle été implémentée comme une mise à jour de l'enregistrement "réel" qui a une clé de partition (p) de 1?

Answer 1

Votre hypothèse est incorrecte. Dans votre schéma, p est la clé de partition (ou "row"), et c est une colonne de clustering. Cassandra est un magasin en colonnes, donc les écritures sont essentiellement une collection de colonnes ordonnées et éparses attachées à une partition. Il est possible d'obtenir imbrication supplémentaire en créant des clés composites de ligne et les noms de colonnes, qui dans votre cas se traduit par un modèle de stockage qui ressemble à ceci:

Row Key: 1 => 
    1:d => "text-1" 
    2:d => "text-2" 

Si vous deviez insérer une autre clé de partition, comme ceci:

INSERT INTO t (p, c, d) VALUE (2, 1, "text-1"); 

votre modèle de stockage ressemblerait à ceci:

Row Key: 1 => 
    1:d => "text-1" 
    2:d => "text-2" 
Row Key: 2 => 
    1:d => "text-1" 

vous pouvez donc constater que ces valeurs de la colonne (1:d, 2:d, etc.), sont traités indépendamment. Supposons que vous supprimez ensuite une de ces valeurs:

DELETE FROM t WHERE p = 1 AND c = 1; 

votre résultat serait:

Row Key: 1 => 
    1:d => "text-1" + [tombstone] 
    2:d => "text-2" 
Row Key: 2 => 
    1:d => "text-1" 

où la pierre tombale aurait un plus grand horodatage et donc « couvrir » la valeur d'origine, jusqu'à ce que le compactage nettoie cette place . Lorsque cela se produit exactement dépend d'un certain nombre de facteurs (valeur de gc_grace_seconds, stratégie de compactage, charge de travail, etc.).

Answer 2

Je crois comprendre que Cassandra ne supprime pas les enregistrements sur insert/update (upsert), il enregistre simplement les nouvelles informations en écriture et ne crée pas de pierre tombale. Lorsque l'information est lue, elle utilisera un horodatage pour déterminer quelles données sont les plus à jour. Les anciens enregistrements sont supprimés pendant le compactage tandis que les pierres tombales restent actives jusqu'à l'expiration de la période de grâce (10 jours par défaut) afin de maintenir la cohérence d'une suppression afin qu'elles ne soient pas ressuscitées.