Types de pierres tombales
Les pierres tombales peuvent être créées de plusieurs façons et il est crucial que vous compreniez certains pièges qui peuvent conduire à la création implicite de pierres tombales qui resteront cachées du point de vue du programmeur jusqu’à ce qu’elles apparaissent comme un problème plausible affectant votre cluster. Par conséquent, il est important de comprendre les types de pierres tombales qui peuvent être créées dans Cassandra:
Pierres tombales de cellules
Les instructions Insert peuvent créer des pierres tombales lorsqu’une certaine valeur de cellule est définie comme nulle dans la requête. Cela peut se produire lorsque la couche d’abstraction de base de données ou un framework ORM fait abstraction de la requête avec une représentation au niveau de l’objet et que les valeurs null sont implicitement envoyées dans la requête réelle à Cassandra. Par exemple, considérez la requête CQL suivante:
INSERT INTO item_price ( store_number, item_id, price, replacements, product_code ) VALUES ( 'CA104', 'item104', 2.50, null , 'p104');
Cela créerait une pierre tombale de cellule pour la colonne remplacements de l’enregistrement avec store_number CA104.
Considérons maintenant la requête de suppression suivante:
DELETE replacements FROM item_price WHERE store_number = 'CA104';
Cela créerait également une pierre tombale de cellule pour l’enregistrement correspondant.
Pierres tombales de ligne
Une ligne entière est marquée comme pierre tombale à la suite d’une requête de suppression qui identifie une ligne. Par exemple:
DELETE FROM item_price WHERE store_number = 'CA101' and item_id='item101' and price = 1.80;
Sstabledump affichera une deletion_info au niveau de la ligne pour les colonnes de clustering dans la partition.
,
"position" : 0
},
"rows" : ,
"deletion_info" : {
"marked_deleted" : "2020-07-05T07:26:52.233374Z",
"local_delete_time" : "2020-07-05T07:26:52Z"
},
"cells" :
}
]
}
]
Un grand nombre de pierres tombales de lignes peut indiquer un modèle de données médiocre dans lequel votre application supprime fréquemment des enregistrements d’une table. Dans de tels cas, envisagez de revoir votre modèle de données et de repenser les tables en fonction des modèles de requête et de la cardinalité.
Pierres tombales de plage
Suppression d’une plage entière de lignes à l’aide de la clause WHERE avec une clé de partition et une plage représentée par une colonne de regroupement. Par exemple:
DELETE FROM item_price WHERE store_number = 'CA101' AND item_id='item101' AND price > 2.0;
SSTabledump montrerait,
,"position" : 0
},
"rows" : ,
"deletion_info" : { "marked_deleted" : "2020-07-05T06:53:50.671654Z", "local_delete_time" : "2020-07-05T06:53:50Z" }
}
},
{
"type" : "range_tombstone_bound",
"end" : {
"type" : "inclusive",
"clustering" : ,
"deletion_info" : { "marked_deleted" : "2020-07-05T06:53:50.671654Z", "local_delete_time" : "2020-07-05T06:53:50Z" }
}
}
]
}
}}
Le SSTabledump imprimerait des pierres tombales de plage avec un type de range_tombstone_bound avec un début et une fin de la clé de clustering utilisée pour désigner la plage de lignes qui ont été gravées dans une partition. Les pierres tombales de plage sont également créées lorsqu’une collection entière est remplacée par une requête d’INSERTION ou de MISE À JOUR. Il est toujours recommandé de remplacer des éléments spécifiques d’une collection plutôt que de remplacer la collection entière elle-même.
Pierres tombales de partition
Les pierres tombales de ce type sont créées lorsqu’une requête delete est déclenchée en utilisant uniquement la clé de partition dans la clause WHERE. Par exemple:
DELETE FROM item_price WHERE store_number = 'CA102';
Comme vous l’avez sans aucun doute deviné, cela supprimerait la partition entière CA102 et le sstabledump montrerait à la partition l’attribut deletion_info avec l’horodatage marked_deleted.
,
"position" : 0,
"deletion_info" : {
"marked_deleted" : "2020-07-05T22:11:48.367057Z",
"local_delete_time" : "2020-07-05T22:11:48Z"
}
},
"rows" :
}
]
Pierres tombales TTL
Ce sont des pierres tombales créées automatiquement lorsque le délai de vie expire pour une ligne ou une cellule particulière. Cependant, ils sont marqués différemment des pierres tombales normales.
L’instruction insert suivante créerait une pierre tombale TTL après 20 secondes.
INSERT INTO item_price ( store_number, item_id, price, replacements, product_code) VALUES ( 'CA103', 'item103', 3.0, {'item101-r', 'item101'}, 'p103') using TTL 20;
Le sstabledump montrerait:
,
"position" : 78
},
"rows" : ,
"liveness_info" : { "tstamp" : "2020-07-05T06:47:51.458099Z", "ttl" : 20, "expires_at" : "2020-07-05T06:48:11Z", "expired" : true },
"cells" : }
]
}
]
}
]
Résumé
- Cassandra traite une requête de suppression en interne comme une opération de mise à jour qui ajoute un marqueur appelé pierre tombale sur les données à supprimer.
- Les pierres tombales peuvent être configurées avec un délai d’expiration (gc_grace_seconds) et sont nettoyées pendant le processus de compactage.
- l’utilitaire sstabledump peut être utilisé pour afficher le contenu d’un fichier SSTable dans un format lisible par l’homme.
- Évitez d’écrire des valeurs Nulles dans vos tables, car il peut y avoir des pierres tombales. Faites attention lorsque vous faites des requêtes abstraites par votre couche ORM.
- Les pierres tombales de gamme sont préférées aux pierres tombales de cellules ou de rangées car elles stockent simplement les limites de la plage en économisant de l’espace disque.
- Évitez de remplacer des éléments entiers d’une collection comme l’ensemble, la liste, la carte par des requêtes d’INSERTION et de MISE À JOUR car cela peut créer des pierres tombales de plage.