Avant une montée en charge ou une migration, un cluster Cassandra se juge sur sa latence p99 et sur la santé de son modèle de données. Expert Cassandra indépendant, j’interviens sur la modélisation, les réparations, les compactions et le multi datacenters, avec Cassandra et ScyllaDB en production. Point de preuve : performance et fiabilité de Cassandra chez BPCE-IT pour une plateforme d’API Management. Références complètes disponibles sous NDA.
Audit et tuning
Le modèle de données d’abord : partitions trop larges ou trop fines, clés de partition mal réparties, tables qui accumulent des tombstones. Ensuite l’exécution : stratégie de compaction adaptée au profil de lecture, configuration du garbage collector, cohérence des lectures au niveau requis sans payer un quorum inutile. Chaque suspect est confirmé par la trace et par la métrique, jamais par intuition.
Montée en charge et multi datacenters
Ajouter des nœuds sans rééquilibrage douloureux demande un design de topologie propre : NetworkTopologyStrategy par datacenter, facteurs de réplication par charge, placement des clients au plus près des réplicas. Le plan de croissance couvre l’ajout de nœuds, la capacité de réparation associée et le scénario de perte d’un datacenter, documenté et testé plutôt que supposé.
Benchmark
La mesure porte sur la latence p99 et le débit soutenu, pas sur une moyenne flatteuse : cassandra-stress ou nosqlbench configurés sur votre profil de charge réel, mélange lecture et écriture, concurrence applicative reproduite. Un benchmark Cassandra qui ne rapporte pas la queue de distribution ne dit rien de ce que vos utilisateurs subiront.
Ce n’est ni du renfort d’équipe ni du développement : pour un point technique unique, la revue flash suffit.
FAQ
Pourquoi la latence Cassandra dégrade-t-elle par pics plutôt qu’en moyenne ?
Parce que la majorité des lectures est servie par des réplicas sains et que la queue de distribution dépend des cas rares : réparation en retard, compaction en cours, partitions larges, tombstones à filtrer. La moyenne reste verte pendant que la p99 dégrade l’expérience. Le tuning Cassandra consiste précisément à attaquer cette queue, pas la moyenne.
Comment savoir si mon modèle de données Cassandra est sain ?
Un modèle sain place la clé de partition selon la requête principale, garde les partitions dans une taille exploitable sans latence excessive et limite les collections qui génèrent des tombstones. L’audit vérifie ces trois points table par table avec les métriques réelles, puis propose les migrations de schéma qui corrigent sans coupure.
Faut-il ajouter des nœuds ou revoir le modèle de données ?
Ajouter des nœuds règle un déficit de capacité, pas un défaut de modélisation : des partitions mal dessinées restent lentes sur un cluster plus grand, et la facture suit. Le bon ordre consiste à corriger le modèle et la configuration, puis à dimensionner le cluster qui reste nécessaire, souvent plus petit que prévu.