Cas pratiques Cassandra

Contexte : Un cluster Cassandra en production fonctionne avec un facteur de réplication de 1. Le Problème : Une panne d’un nœud entraîne une indisponibilité des données. Configuration actuelle : 'replication_factor': 1 Cette configuration ne garantit aucune tolérance aux pannes. Contraintes : Augmenter le facteur de réplication sans provoquer d’indisponibilité prolongée. Assurer la cohérence minimale nécessaire. Livrable attendu : Proposer une modification de configuration du keyspace améliorant la résilience du cluster.

Contexte : Une application stocke des codes de validation temporaires dans Cassandra. Le Problème : Les enregistrements ne sont jamais supprimés automatiquement. Extrait actuel : INSERT INTO codes (user_id, code) VALUES ('u1', '123456'); Aucun TTL n’est défini. Contraintes : Ajouter un TTL de 10 minutes lors de l’insertion. Ne pas modifier la structure de la table existante. Livrable attendu : Corriger la requête d’insertion afin d’appliquer une expiration automatique aux données temporaires.

Contexte : Une erreur apparaît lors d’une insertion dans une table Cassandra. Le Problème : La requête INSERT ne fournit pas toutes les colonnes composant la clé primaire. Extrait actuel : INSERT INTO orders (order_date, amount) VALUES ('2024-01-01', 100); La partition key client_id est absente. Contraintes : Fournir toutes les colonnes nécessaires à la clé primaire. Maintenir la cohérence du modèle. Livrable attendu : Corriger la requête d’insertion afin de respecter la définition complète de la clé primaire.

Contexte : Une application enregistre les événements utilisateurs dans Cassandra. Le Problème : Toutes les écritures utilisent la même clé de partition. Extrait actuel : PRIMARY KEY (event_type, event_time) Le champ event_type contient une seule valeur dominante, provoquant un hotspot. Contraintes : Revoir la partition key pour répartir correctement les données sur le cluster. Maintenir la capacité à interroger par type d’événement. Livrable attendu : Corriger le modèle de table afin d’éviter les hotspots et assurer une distribution équilibrée des données.

Contexte : Une requête Cassandra retourne une erreur ou nécessite ALLOW FILTERING pour fonctionner. Le Problème : La requête actuelle filtre sur une colonne non indexée. Extrait actuel : SELECT * FROM users WHERE age = 30 ALLOW FILTERING; Cette pratique dégrade fortement les performances. Contraintes : Modifier le modèle de données ou créer un index approprié. Éviter l’utilisation de ALLOW FILTERING en production. Livrable attendu : Proposer une solution permettant d’exécuter la requête efficacement sans ALLOW FILTERING.

Contexte : Une application de monitoring doit stocker des métriques horodatées et les consulter par intervalle de temps. Le Problème : Le modèle actuel ne permet pas de requêter efficacement une plage de dates. Contraintes : Utiliser une partition key appropriée et une clustering key basée sur le timestamp. Optimiser pour les lectures séquentielles. Livrable attendu : Proposer un schéma Cassandra permettant de stocker et récupérer efficacement des données temporelles par plage donnée.

Contexte : Une application doit stocker des profils utilisateurs dans Cassandra pour des lectures rapides. Le Problème : L’équipe n’a pas encore implémenté les requêtes CQL nécessaires pour insérer et récupérer les données. Contraintes : Créer une table simple avec une partition key unique. Écrire une requête INSERT et une requête SELECT permettant de récupérer un profil par identifiant utilisateur. Livrable attendu : Fournir les requêtes CQL nécessaires pour créer la table et effectuer des opérations d’insertion et de lecture basiques.

Contexte : Une application doit permettre de rechercher des utilisateurs par email. Le Problème : La colonne email n’est pas incluse dans la clé primaire. Contraintes : Créer un index secondaire sur la colonne email. Évaluer les impacts potentiels sur les performances. Livrable attendu : Fournir la commande CQL permettant de créer un index secondaire et expliquer brièvement son usage dans ce contexte.

Contexte : Votre cluster Cassandra contient plusieurs nœuds répartis sur différents datacenters. Le Problème : Le keyspace actuel utilise une stratégie de réplication par défaut non adaptée à la haute disponibilité. Contraintes : Configurer une stratégie de réplication SimpleStrategy ou NetworkTopologyStrategy selon le contexte. Définir un facteur de réplication approprié. Livrable attendu : Fournir une commande CQL permettant de créer ou modifier un keyspace avec une stratégie de réplication adaptée.

Contexte : Votre équipe développe une application e-commerce qui doit enregistrer les commandes clients avec un fort volume d’écriture. Le Problème : La base relationnelle actuelle montre des limites en performance sous forte charge. Contraintes : Concevoir une table Cassandra adaptée à une lecture fréquente par identifiant client. Définir une clé primaire appropriée incluant partition key et clustering key. Optimiser pour les requêtes les plus fréquentes. Livrable attendu : Proposer un schéma Cassandra (CREATE TABLE) optimisé pour récupérer efficacement les commandes d’un client donné, triées par date.

Contexte : Vous développez une application sociale où chaque utilisateur possède un fil d’actualité personnalisé affichant ses 50 derniers événements. Le Problème : Le modèle actuel entraîne des lectures coûteuses et nécessite des filtrages côté application. Contraintes : Concevoir une table optimisée pour récupérer rapidement les 50 derniers posts d’un utilisateur. Utiliser une partition key adaptée et une clustering key basée sur le timestamp décroissant. Éviter ALLOW FILTERING. Livrable attendu : Proposer un schéma CQL optimisé et expliquer le choix de la clé primaire afin d’assurer des performances constantes à grande échelle.

Contexte : Une table utilise plusieurs index secondaires pour permettre des recherches flexibles. Le Problème : Les performances se dégradent fortement sous forte charge. Extrait actuel : CREATE INDEX ON users(age); CREATE INDEX ON users(city); Les requêtes combinées deviennent coûteuses. Contraintes : Réviser le modèle pour éviter l’utilisation excessive d’index secondaires. Optimiser pour les requêtes réellement utilisées. Livrable attendu : Proposer une alternative basée sur une table dédiée ou un autre modèle de données plus performant.

Contexte : Une application critique effectue des écritures avec un niveau de cohérence ONE. Le Problème : Des incohérences apparaissent lors de lectures rapides après écriture. Extrait actuel : CONSISTENCY ONE; Les données ne sont pas immédiatement visibles sur tous les nœuds. Contraintes : Ajuster le niveau de cohérence pour garantir une meilleure cohérence sans sacrifier excessivement les performances. Livrable attendu : Proposer un niveau de cohérence plus adapté (par exemple QUORUM) et expliquer l’impact sur la disponibilité et la latence.

Contexte : Les performances du cluster Cassandra diminuent lors des opérations de compaction. Le Problème : La stratégie de compaction actuelle n’est pas adaptée au type de données stockées. Configuration actuelle : compaction = {'class': 'SizeTieredCompactionStrategy'} Cette stratégie peut être inefficace pour des données time-series. Contraintes : Choisir une stratégie de compaction adaptée (par exemple Leveled ou TimeWindow). Minimiser l’impact sur la production. Livrable attendu : Proposer une configuration de compaction optimisée adaptée au type de workload observé.

Contexte : L’analyse des métriques montre que certaines partitions sont beaucoup plus volumineuses que d’autres. Le Problème : Une clé de partition basée sur user_id provoque des déséquilibres car certains utilisateurs génèrent beaucoup plus de données. Contraintes : Introduire un bucketing ou un partitionnement supplémentaire pour répartir la charge. Maintenir la capacité de requêter efficacement les données par utilisateur. Livrable attendu : Proposer une stratégie de partitionnement améliorée réduisant le déséquilibre des partitions.

Contexte : Le cluster Cassandra montre une dégradation de performance lors des lectures. Le Problème : De nombreuses suppressions avec TTL génèrent un volume important de tombstones. Extrait actuel : INSERT INTO logs (id, message) VALUES (1, 'test') USING TTL 60; Des millions d’enregistrements expirent fréquemment. Contraintes : Réduire la génération excessive de tombstones. Adapter la stratégie de stockage ou de partitionnement. Maintenir la capacité de suppression automatique. Livrable attendu : Proposer une modification du modèle ou de la stratégie d’écriture permettant de limiter l’impact des tombstones sur les performances.

Contexte : Une plateforme collecte des millions d’événements par heure. Le Problème : Le modèle actuel entraîne des partitions trop volumineuses, provoquant des ralentissements. Contraintes : Concevoir un modèle permettant de répartir les logs par période (ex : par jour ou par heure). Limiter la taille des partitions. Optimiser les lectures récentes. Livrable attendu : Proposer un schéma Cassandra optimisé pour la gestion de gros volumes de logs avec justification des choix de partitionnement.

Contexte : Une API doit retourner des résultats paginés à partir d’une table Cassandra contenant des milliers d’enregistrements par partition. Le Problème : La pagination actuelle est gérée côté application avec OFFSET, ce qui n’est pas adapté à Cassandra. Contraintes : Utiliser le mécanisme natif de pagination Cassandra (paging state). Optimiser pour des lectures progressives sans surcharge mémoire. Livrable attendu : Proposer une stratégie de pagination efficace compatible avec Cassandra et expliquer son fonctionnement.

Contexte : Votre application est déployée sur deux datacenters pour assurer la haute disponibilité. Le Problème : La configuration actuelle ne tient pas compte des spécificités multi-DC et peut provoquer une latence excessive. Contraintes : Utiliser NetworkTopologyStrategy. Définir un facteur de réplication adapté par datacenter. Garantir une cohérence adaptée aux lectures locales. Livrable attendu : Proposer une configuration CQL du keyspace adaptée à un environnement multi-datacenter avec justification du niveau de cohérence choisi.

Contexte : Une application effectue de nombreuses lectures répétées sur les mêmes partitions. Le Problème : Les latences augmentent lors des pics d’activité. Contraintes : Analyser les patterns de requêtes. Ajuster le modèle de données ou le niveau de cohérence pour améliorer les performances. Éviter toute opération de scan complet. Livrable attendu : Proposer des optimisations concrètes permettant de réduire la latence des lectures fréquentes dans Cassandra.

Contexte : Une plateforme IoT collecte des milliards d’événements par jour provenant de capteurs répartis mondialement. Le Problème : Les partitions deviennent instables et certaines requêtes de lecture historique sont trop lentes. Contraintes : Concevoir un modèle time-series avec partitionnement par fenêtre temporelle et identifiant de capteur. Limiter la taille des partitions. Optimiser pour les lectures récentes. Livrable attendu : Proposer un schéma Cassandra scalable permettant d’absorber un volume massif d’écritures tout en maintenant des performances de lecture acceptables.

Contexte : Votre application est déployée sur trois régions géographiques distinctes avec des exigences fortes de disponibilité mondiale et de latence faible. Le Problème : Une coupure réseau inter-région peut provoquer des incohérences ou une indisponibilité partielle selon les niveaux de cohérence choisis. Contraintes : Utiliser NetworkTopologyStrategy avec réplication par région. Définir des niveaux de cohérence adaptés aux lectures locales et globales. Garantir un équilibre entre cohérence et disponibilité. Livrable attendu : Proposer une architecture Cassandra multi-régions détaillant stratégie de réplication, niveaux de cohérence recommandés et mécanismes de résilience face aux partitions réseau.

Contexte : Les métriques montrent que certains nœuds Cassandra sont surchargés alors que d’autres sont sous-utilisés. Le Problème : La distribution des tokens n’est pas équilibrée. Configuration actuelle : num_tokens: 1 La répartition n’est pas optimale. Contraintes : Ajuster la configuration de num_tokens ou rééquilibrer le cluster. Minimiser l’impact sur la production. Livrable attendu : Proposer une stratégie de rééquilibrage des tokens améliorant la distribution des données et la charge sur les nœuds.

Contexte : Une table Cassandra stocke l’historique complet des transactions financières par client. Le Problème : Certains clients génèrent des millions d’enregistrements, créant des partitions extrêmement volumineuses qui dégradent les performances. Extrait actuel : PRIMARY KEY (client_id, transaction_time) Toutes les transactions d’un client sont dans la même partition. Contraintes : Réduire la taille des partitions sans perdre la capacité de requêter efficacement par client et par date. Minimiser les migrations massives de données. Livrable attendu : Proposer une stratégie avancée de partitionnement (bucketing temporel ou hashing) permettant d’éviter les partitions surdimensionnées.

Contexte : Une application critique utilise Cassandra avec un niveau de cohérence faible pour maximiser la disponibilité. Le Problème : Des anomalies sont observées lors de lectures rapides après écriture dans un environnement multi-réplica. Extrait actuel : CONSISTENCY ONE; Les données lues ne reflètent pas toujours les dernières écritures. Contraintes : Ajuster les niveaux de cohérence en tenant compte du théorème CAP. Garantir une cohérence suffisante pour les opérations sensibles. Livrable attendu : Définir une stratégie de cohérence adaptée aux exigences métier en équilibrant disponibilité, latence et exactitude des données.

Contexte : Une requête analytique tente de récupérer des données sans spécifier la clé de partition. Le Problème : La requête provoque un scan distribué sur tout le cluster. Extrait actuel : SELECT * FROM transactions WHERE amount > 1000; La partition key n’est pas utilisée. Contraintes : Adapter le modèle ou créer une table dédiée aux requêtes analytiques. Éviter tout scan complet en production. Livrable attendu : Proposer une refonte du modèle permettant d’exécuter efficacement ce type de requête sans scan global.

Contexte : Cassandra stocke des données critiques mais aucune procédure formelle de sauvegarde et restauration n’est documentée. Le Problème : En cas de corruption ou suppression accidentelle, la récupération des données est incertaine. Contraintes : Mettre en place une stratégie basée sur snapshots et sauvegardes incrémentales. Garantir la cohérence des données restaurées dans un cluster multi-nœuds. Livrable attendu : Définir une stratégie de backup et restauration détaillée assurant intégrité, cohérence et reprise rapide après incident.

Contexte : Les lectures sur un cluster Cassandra multi-DC montrent une latence importante en heures de pointe. Le Problème : Les niveaux de cohérence et la stratégie de réplication ne sont pas optimisés pour les lectures locales. Contraintes : Ajuster les niveaux de cohérence (LOCAL_QUORUM si nécessaire). Optimiser les requêtes et le partitionnement. Maintenir la disponibilité globale. Livrable attendu : Proposer un plan d’optimisation combinant configuration réseau, réplication et niveau de cohérence pour réduire la latence des lectures.

Contexte : Le cluster Cassandra traite un volume important de données temporaires avec TTL court. Le Problème : L’accumulation de tombstones provoque des latences élevées lors des lectures et des compactions fréquentes. Contraintes : Adapter la stratégie de compaction (TimeWindowCompactionStrategy si nécessaire). Réduire la fragmentation des données expirées. Maintenir la suppression automatique via TTL. Livrable attendu : Proposer une stratégie complète combinant modèle de données et configuration de compaction pour réduire l’impact des tombstones sur les performances.

Contexte : Un cluster Cassandra est accessible depuis plusieurs réseaux internes sans authentification stricte. Le Problème : Les accès ne sont pas correctement contrôlés et aucune séparation des rôles n’est définie. Configuration actuelle : authenticator: AllowAllAuthenticator Le cluster accepte toutes les connexions. Contraintes : Activer l’authentification, configurer des rôles et permissions adaptées, sécuriser les communications entre nœuds. Livrable attendu : Proposer une configuration sécurisée du cluster incluant authentification, autorisations granulaires et chiffrement des communications.