Examen du Cycle de vie des pierres tombales dans Apache Cassandra

Cet article est la première partie d’une série d’articles de blog concernant le cycle de vie et la gestion des pierres tombales.

La suppression et l’expiration des données dans Cassandra sont quelque chose que vous devez soigneusement planifier. Surtout si vous êtes sur le point de supprimer une énorme quantité de données à la fois. Sans une planification appropriée, cela peut poser des problèmes au cluster, comme une augmentation de la latence de lecture et de l’empreinte d’utilisation du disque. Tout au long de cet article, je décrirai une façon de s’attaquer à cela et à ses mises en garde.

Tout d’abord, passons en revue les bases. Dans Cassandra, les fichiers de données (SSTables) existant sur le disque sont des fichiers immuables. Lorsque nous supprimons quelque chose dans Cassandra, un nouveau SSTable contenant un marqueur est créé. Ce marqueur indique quelle partition, ligne ou cellule a été supprimée ainsi que l’horodatage de cette suppression. Ce marqueur de suppression s’appelle une pierre tombale.

Les données supprimées et la pierre tombale peuvent coexister sur le disque pendant une période appelée gc_grace_seconds, qui est par défaut de 10 jours. Pendant ce temps, bien que les données puissent toujours exister sur le lecteur, elles ne sont pas renvoyées au client si elles sont interrogées. Ce qui signifie que du point de vue du client, les données sont supprimées dès que vous exécutez l’instruction delete. Cependant, d’un point de vue opérationnel, les données et la pierre tombale peuvent toujours exister et occuper de l’espace sur le disque. Ces données supprimées qui existent toujours sur le disque sont appelées « données ombragées. »

N.B.: Dans le paragraphe précédent, je dis que les données et les pierres tombales « peuvent toujours coexister sur disque » (accent sur la « boîte ») car si un compactage se produit qui implique les données et les pierres tombales, les données sont expulsées. Mais la pierre tombale restera si gc_grace_seconds n’est pas passé.

Le gc_grace_seconds est un mécanisme de sécurité pour s’assurer que la pierre tombale a suffisamment de temps pour se répliquer sur tous les nœuds qui ont une réplique des données ombrées. Pour que ce mécanisme de sécurité réussisse, vous devez pouvoir réparer le cluster toutes les secondes de gc_grace_seconds. Cela signifie que si vous utilisez les 10 jours par défaut pour gc_grace_seconds, une réparation doit être démarrée et terminée tous les 10 jours. La réparation sert à empêcher les données zombies dans le cluster. Je n’entrerai pas dans les détails de la façon dont cela peut se produire, mais fondamentalement, les données zombies se produisent lorsque vous supprimez des données, mais elles reviennent quelque temps plus tard.

Après le passage de gc_grace_seconds, les données et la pierre tombale peuvent enfin être expulsées du disque, récupérant l’espace disque précédemment utilisé par eux (Figure 1). L’ETA pour libérer de l’espace disque est l’un des premiers points que je souhaite clarifier dans cet article. Lors de l’utilisation de Cassandra, beaucoup de gens trouvent ce mécanisme surprenant, c’est-à-dire qu’après la suppression des données, les données existent toujours sur le disque. Cette confusion est généralement rapidement clarifiée dès que les gens apprennent les pierres tombales et gc_grace_seconds. Cependant, il semble que les opérateurs aient tendance à penser que les données et les pierres tombales sont expulsées juste après la fin de gc_grace_seconds. En fait, il est essentiel d’être conscient que cela pourrait ne pas (et tend à ne pas) être vrai. Habituellement, il faut plus de temps que gc_grace_seconds pour que cette expulsion se produise et que l’espace disque soit récupéré.

Figure 1 – compactage des données ombragées avec des pierres tombales expirées et non expirées

L’expulsion mentionnée ci-dessus se produit lorsque le compactage implique les tables S qui ont les données ombragées et la pierre tombale. Ce n’est qu’alors que les données sont effectivement supprimées et que l’espace disque est récupéré. Il est important de noter que même si gc_grace_seconds est passé et que la table SSTable avec les données shadowed est compactée avec une autre table SSTable qui n’a pas la pierre tombale, les données shadowed ne sont pas purgées. La même chose se produit pour les marqueurs de pierre tombale, c’est-à-dire que si le SSTable avec la pierre tombale n’est pas compacté avec tous les SSTables qui ont encore des données qui ont été supprimées, la pierre tombale n’est pas expulsée du disque. La raison pour laquelle cela se produit est que pendant le compactage, Cassandra ne sait pas ce qui se trouve dans les tables SSTables qui ne sont pas impliquées dans le compactage. Il n’a donc aucun moyen de savoir qu’il peut rejeter les données car il ne peut pas voir la pierre tombale. Vous pouvez le voir sur la figure 2 où, bien que gc_grace_seconds soit passé pour les deux pierres tombales, rien n’est expulsé après le compactage.

Figure 2 – compactage des données ombragées et de leurs pierres tombales séparément

En raison de l’utilisation du disque par les données et le marqueur de pierre tombale, l’accumulation de pierres tombales peut avoir un impact sur la latence de lecture, car Cassandra doit lire beaucoup de pierres tombales avant de renvoyer des données en direct.

La suppression de données n’est généralement pas un problème si ces suppressions sont petites et rares. Parce que, au cours du cycle de vie du compactage naturel, Cassandra récupère finalement l’espace disque et les pierres tombales purgées. Cependant, si vous supprimez une grande quantité de données à la fois, cela crée de nombreuses pierres tombales et peut rapidement avoir un impact sur votre latence de lecture.

Si vous devez supprimer une grande quantité de données sur une base ad hoc, vous pouvez prendre certaines mesures dans le prochain article de blog pour atténuer les risques.

courriel

Auteur

  • Pedro Gordo

Intéressé à travailler avec Pedro? Planifiez un appel technique.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.