Cassandra: entretien

Je n'ai pas d'expérience avec Cassandra, mais j'ai une certaine expérience avec les bases de données relationnelles basées sur SQL.

Je n'ai pas été en mesure de trouver des informations sur les meilleures pratiques concernant la maintenance de Cassandra une fois déployée. Faut-il VACUUM la base de données? Je devrais penser que les charges de lecture / écriture provoquent une fragmentation du stockage.

Ou plus généralement: quelles sont les meilleures pratiques pour maintenir un déploiement de production Cassandra? Que faut-il faire à intervalles réguliers pour maintenir la santé du système? Le manuel d'exploitation ne traite pas vraiment de cet aspect.

Merci.

En général, un cluster bien conçu peut vivre des ANNÉES sans être touché. J'ai eu des grappes qui ont fonctionné pendant des années sans intervention. Cependant, voici quelques directives:

La surveillance est extrêmement importante:

1) Surveillez les latences. Utilisez opscenter ou vos outils de mesure préférés pour suivre les latences. Les latences qui augmentent peuvent être des signes de problèmes à venir, y compris des pauses GC (plus courantes dans les charges de travail en lecture que dans les charges de travail en écriture), des problèmes instables, etc.

2) Surveillez les comptes stables. Le nombre de SSTables augmentera si vous dépassez le compactage (chaque sstable est écrite exactement une fois - les suppressions sont gérées en combinant d'anciennes sstables dans de nouvelles sstables via le compactage).

3) Surveiller les changements d'état des nœuds (haut / bas, etc.). Si vous voyez des nœuds battre, examinez, car ce n'est pas normal.

4) Gardez une trace de votre utilisation du disque - traditionnellement, vous devez rester inférieur à 50% (surtout si vous utilisez le compactage STCS).

Il y a certaines choses de base que vous devriez et ne devriez pas faire régulièrement:

1) Ne pas exécuter explicitement nodetool compact. Vous mentionnez que vous l'avez fait, ce n'est pas fatal, mais cela crée de très grandes écuries, qui sont alors moins susceptibles de participer au compactage à l'avenir. Vous n'avez pas nécessairement besoin de continuer à l'exécuter, mais parfois cela peut aider à se débarrasser des données supprimées / écrasées.

2) nodetool repairest généralement recommandé tous les gc_grace_seconds(10 jours par défaut). Il y a des charges de travail où cela est moins important - la principale raison pour laquelle VOUS AVEZ BESOIN de réparation est de vous assurer que les marqueurs de suppression ( tombstones) sont transmis avant leur expiration (ils survivent gc_grace_seconds, si un nœud est arrêté lorsque la suppression s'est produite, que les données peuvent reprendre vie) sans la réparation!). Si vous n'effectuez pas de suppressions et que vous interrogez avec un niveau de cohérence suffisant (lectures et écritures sur QUORUM, par exemple), vous pouvez réellement vivre une vie sans réparation.

3) Si vous envisagez de réparer, envisagez d'utiliser la réparation incrémentielle et réparez de petites plages à la fois.

4) Les stratégies de compactage sont importantes. STCS est idéal pour les écritures, LCS est idéal pour les lectures. DTCS a quelques bizarreries.

5) Les modèles de données sont importants - tout comme les environnements RDBMS / SQL rencontrent des problèmes lorsque des requêtes non indexées atteignent de grandes tables, Cassandra peut être problématique avec de très grandes lignes / partitions.

6) Les instantanés sont bon marché. Vraiment pas cher. Presque instantanés, juste des liens durs, ils ne coûtent presque pas d'espace disque immédiatement. Utilisez l'instantané avant de mettre à niveau les versions, en particulier les versions majeures.

7) Soyez prudent avec les suppressions. Comme indiqué dans # 2, la suppression crée plus de données sur le disque et ne les libère PAS AU MOINS gc_grace_seconds.

Quand tout le reste échoue:

J'ai vu des articles qui suggèrent que Cassandra in prod nécessite une tête dédiée pour gérer n'importe quel cluster de taille - je ne sais pas si c'est nécessairement vrai, mais si vous êtes inquiet, vous voudrez peut-être embaucher un consultant tiers (TheLastPickle, Pythian ) ou avoir un contrat de support (Datastax) pour vous donner une tranquillité d'esprit.

Selon la documentation de réparation Cassandra , nodetool repairdoit être exécuté dans les situations suivantes:

• En tant que meilleure pratique, vous devez planifier les réparations chaque semaine. Remarque: Si des suppressions ne se produisent jamais, vous devez quand même planifier des réparations régulières. Sachez que définir une colonne sur null est une suppression.
• Pendant la récupération du nœud. Par exemple, lors du retour d'un nœud dans le cluster après une panne.
• Sur les nœuds contenant des données qui ne sont pas lues fréquemment.
• Pour mettre à jour les données sur un nœud qui a été arrêté.

Je devrais penser que les charges de lecture / écriture provoquent une fragmentation du stockage.

Les données de Cassandra ne se «fragmentent» pas comme vous le pensez. Cependant, les suppressions déclenchent le placement des pierres tombales et le processus compact normal élimine les pierres tombales.

Je comprends maintenant que le compactage est un gros problème et fonctionne automatiquement

Correct. Un représentant de DataStax m'a dit qu'une fois que vous exécutez compactmanuellement, vous devrez toujours l'exécuter manuellement. La raison en est que le compactage fonctionne en «compactant» tous les SSTABLES existants dans un espace de clés en un seul fichier SSTABLE. Vous pouvez avoir des familles de colonnes dans ce fichier SSTABLE qui sont petites et prendront tellement de temps pour augmenter au-delà du seuil de compactage, que la probabilité que le compactage automatique se réexécute est très faible.

Essentiellement, assurez-vous de planifier une nodetool repairexécution régulière , de ne jamais exécuter nodetool compactet d'implémenter une stratégie de sauvegarde (instantanés, sauvegardes incrémentielles, ou les deux).