Cassandra génère des pierres tombales lorsque vous supprimez des données. Dans certaines circonstances, un excès de pierres tombales peut provoquer de longues pauses GC, une latence, des échecs de lecture ou des erreurs de tas. Cet article fournit des conseils pour la gestion des pierres tombales.

Table des matières

Qu’est-ce qu’une pierre tombale ?

Dans Cassandra, les données supprimées ne sont pas immédiatement purgées du disque. Au lieu de cela, Cassandra écrit une valeur spéciale, connue sous le nom de pierre tombale, pour indiquer que les données ont été supprimées. Les pierres tombales empêchent les données supprimées d’être renvoyées pendant les lectures et permettront éventuellement de les supprimer via le compactage.

Les pierres tombales sont des écritures – elles passent par le chemin d’écriture normal, occupent de l’espace sur le disque et utilisent les mécanismes de cohérence de Cassandra. Les pierres tombales peuvent être propagées à travers le cluster via des astuces et des réparations. Si un cluster est géré correctement, cela garantit que les données resteront supprimées même si un nœud est en panne lors de l’émission de la suppression.

Les pierres tombales sont générées par:

• Instructions de suppression
• Définition de TTLs
• Insertion de valeurs nulles
• Insertion de données dans des parties d’une collection.

Quel est le cycle de vie normal des pierres tombales?

Les pierres tombales sont écrites avec un horodatage. Dans des circonstances idéales, les pierres tombales (et leurs données associées) seront lâchées pendant les compactions après un certain laps de temps.

Les trois critères suivants doivent être remplis pour que les pierres tombales soient retirées :

• Les pierres tombales ont été créées il y a plus de gc_grace_secondes.
• La table contenant la pierre tombale est impliquée dans un compactage.
• Toutes les tables sstables pouvant contenir les données pertinentes sont impliquées dans le compactage.

Chaque table a un paramètre gc_grace_seconds. Par défaut, il est défini sur 864000, ce qui équivaut à 10 jours. L’intention est de donner au cluster le temps d’obtenir une cohérence via des réparations (et donc d’empêcher la résurrection des données supprimées).

Les pierres tombales ne seront lâchées via un compactage que si toutes les tables sstables pouvant contenir les données pertinentes sont impliquées dans le compactage. Si beaucoup de temps s’est écoulé entre l’écriture des données d’origine et l’émission de la SUPPRESSION, cela devient moins probable :

• La stratégie de compactage à plusieurs niveaux de taille compactera ensemble des tables s de taille similaire. Les données ont tendance à se déplacer dans des sstables plus grands à mesure qu’elles vieillissent, il est donc peu probable que la pierre tombale (dans un nouveau sstable petit) soit compactée avec les données (dans un ancien sstable grand).
• La stratégie de compactage nivelée est divisée en plusieurs niveaux qui sont compactés séparément. La pierre tombale sera écrite au niveau 0 et « chassera » efficacement les données à travers les niveaux – elle devrait éventuellement rattraper son retard.
• La Stratégie de compactage à Fenêtre Temporelle (ou Stratégie de compactage à plusieurs niveaux de Date) ne compactera jamais la pierre tombale avec les données si elles sont écrites dans des fenêtres temporelles différentes.

Quand les pierres tombales posent-elles des problèmes?

Utilisation du disque

Lorsque des données sont supprimées, l’espace ne sera pas réellement libéré pendant au moins la période gc_grace définie dans les paramètres de la table. Cela peut poser des problèmes si un cluster se remplit rapidement.

Dans certaines circonstances, l’espace ne sera jamais libéré sans intervention manuelle.

Performances de lecture

De graves problèmes de performances peuvent survenir si les lectures rencontrent un grand nombre de pierres tombales.

Les problèmes de performances sont les plus susceptibles de se produire avec les types de requêtes suivants :

• Requêtes qui s’exécutent sur toutes les partitions d’une table (« select* from keyspace. »)
• Requêtes de plage (« sélectionnez* dans l’espace de clés.table OÙ value > x », ou « OÙ value IN(value1, value2, …) »
• Toute requête qui ne peut être exécutée qu’avec une clause « AUTORISER LE FILTRAGE ».

Ces problèmes de performances sont dus au comportement des pierres tombales lors des lectures. Dans une requête de plage, votre pilote Cassandra utilisera normalement la pagination, ce qui permet aux nœuds de renvoyer un nombre limité de réponses à la fois. Lorsque des pierres tombales de cassandra sont impliquées, le nœud doit conserver en mémoire les pierres tombales qu’il a rencontrées et les renvoyer au coordinateur, au cas où l’une des autres répliques ignorerait que les données pertinentes ont été supprimées. Les pierres tombales ne peuvent pas être paginées car il est essentiel de les retourner toutes, donc la latence et l’utilisation de la mémoire augmentent proportionnellement au nombre de pierres tombales rencontrées.

Si les pierres tombales seront rencontrées dépend de la façon dont les données sont stockées et récupérées. Par exemple, si Cassandra est utilisée pour stocker des données dans une file d’attente (ce qui n’est pas recommandé), les requêtes peuvent rencontrer des dizaines de milliers de pierres tombales pour renvoyer quelques lignes de données.

Comment diagnostiquer les problèmes liés à la pierre tombale ?

Les requêtes qui rencontrent un grand nombre de pierres tombales apparaîtront dans les journaux. Par défaut, une lecture rencontrant plus d’un millier de pierres tombales générera un avertissement :

WARN org.Apache.Cassandre.DB.ReadCommand Lit 0 lignes en direct et 87051 cellules de pierre tombale pour la requête SELECT* DE l’exemple.table

Par défaut, rencontrer plus de 100 000 pierres tombales entraînera l’échec de la requête avec une exception TombstoneOverwhelmingException.

Pour vérifier si les lectures de tombstone causent des problèmes de performances, vérifiez si les lectures sont en corrélation avec une augmentation de la latence de lecture et de la durée de pause GC.

S’il est clair que les pierres tombales sont les problèmes, les techniques suivantes peuvent aider à réduire la portée du problème :

• Le nombre de pierres tombales renvoyées dans une requête particulière peut être trouvé en exécutant la requête dans cqlsh avec le traçage activé.
• Les statistiques pour le nombre de pierres tombales rencontrées récemment dans chaque table sont disponibles dans la sortie de nodetool cfstats.
• Pour les clusters de notre service géré, les statistiques des pierres tombales récemment rencontrées sont disponibles sur la page cluster dans les listes de métriques > Informations sur la table. Cela inclut les cellules vivantes par lecture et les pierres tombales moyennes et maximales par lecture, ventilées par nœud ou table pour une période de temps donnée.
• Des informations plus détaillées sur les pierres tombales stockées peuvent être trouvées à l’aide d’ic-tools.

Comment puis-je éviter les problèmes de pierre tombale?

Les options suivantes peuvent vous aider :

• Évitez les requêtes qui s’exécuteront sur toutes les partitions de la table (par exemple, les requêtes sans clause WHERE, ou toute requête nécessitant un FILTRAGE ALLOW).
• Modifiez les requêtes de plage pour éviter d’interroger des données supprimées ou utilisez une plage de données plus étroite. Les problèmes de performances ne se produisent que si les pierres tombales sont lues et s’adaptent au nombre de pierres tombales lues.
• Concevez le modèle de données pour éviter de supprimer de grandes quantités de données.
• Si vous prévoyez de supprimer toutes les données d’une table, tronquez ou supprimez la table pour supprimer toutes les données sans générer de pierres tombales.
• Utilisez une valeur de durée de vie par défaut. Cela ne fonctionne efficacement que si la clé primaire de vos données est basée sur le temps, vos données sont écrites dans l’ordre chronologique et les données seront supprimées à une date connue. Pour ce faire, définissez un TTL par défaut dans les options au niveau de la table et définissez une stratégie de compactage basée sur le temps (TimeWindowCompactionStrategy si disponible, DateTieredCompactionStrategy sinon). Cela créera toujours des pierres tombales, mais des tables s entières seront efficacement supprimées une fois que le TTL sur tout leur contenu aura passé.

Comment puis-je me débarrasser des pierres tombales existantes?

Dans la plupart des circonstances, la meilleure approche consiste à attendre que la pierre tombale se compacte normalement. Si des problèmes urgents de performances ou d’utilisation du disque nécessitent une action plus immédiate, deux commandes nodetool peuvent être utilisées pour forcer les compactions, ce qui peut aider à faire tomber les pierres tombales. Ceux–ci doivent être considérés comme un dernier recours – dans un cluster sain avec un modèle de données bien conçu, il n’est pas nécessaire d’exécuter des compactions manuelles.

L’exécution de nodetool compact force un compactage de tous les sstables. Cela nécessite une grande quantité d’espace disque libre. Les arguments Espace de clés et table doivent être utilisés pour limiter le compactage aux tables où les pierres tombales posent problème. Sur les tables où une stratégie de compactage à plusieurs niveaux de taille est utilisée, cette commande peut conduire à la création d’un énorme sstable qui n’aura jamais de pairs avec lesquels compacter; si l’indicateur –split-output est disponible, il doit être utilisé.

La commande nodetool garbagecollect est disponible à partir de Cassandra 3.10. Cette commande exécute une série de compactions plus petites qui vérifient également les tables sstables qui se chevauchent. Il consomme plus de CPU et de temps que nodetool compact, mais nécessite moins d’espace disque libre.

Les pierres tombales ne seront supprimées que si gc_grace_secondes se sont écoulées depuis la création des pierres tombales. Le but de gc_grace_seconds est de fournir du temps pour les réparations afin de restaurer la cohérence du cluster, soyez donc prudent lorsque vous le modifiez – la suppression prématurée des pierres tombales peut entraîner la résurrection des données supprimées. De plus, le paramètre gc_grace_seconds affecte l’expiration des indices générés pour le transfert laissé entendre, il est donc dangereux de réduire gc_grace_seconds en dessous de la durée de la fenêtre de transfert laissé entendre (par défaut, 3 heures).

Réparations

Les réparations peuvent retarder ou empêcher la chute des pierres tombales. Lorsqu’une réparation complète ou incrémentielle est exécutée, les tables sstables affectées sont marquées comme réparées ; lors des compactions ultérieures, ces tables seront compactées séparément des tables sstables qui n’ont pas été réparées. Si les pierres tombales sont dans des sstables non appariés et que les données ombrées sont dans des sstables réparés (ou vice versa), les données ne peuvent pas être supprimées car les sstables ne peuvent pas être compactés ensemble.
Si vous effectuez régulièrement des réparations complètes ou incrémentielles sur le cluster, cela ne devrait pas poser trop de problèmes car les pierres tombales et les données finiront par être réparées. Cependant, si vous avez un mélange de données réparées et non réparées et que vous n’effectuez pas régulièrement de réparations, cela peut devenir un problème. sstablemetadata peut vous aider à inspecter l’état réparé de vos sstables pour déterminer si cela se produit. Si c’est le cas, il peut être conseillé de définir tous les sstables comme non appariés avec sstablerepairedset afin qu’ils puissent être compactés ensemble.
Veuillez noter que les réparations de sous-plage ne marquent pas les données comme réparées.