Les anti-patterns ou mauvaises configurations possibles sont légion sous Cassandra, nous allons voir les principaux auxquels nous avons été confrontés que ce soit au niveau du matériel, de la modélisation ou encore de la configuration.
Rappel : la modélisation sous Cassandra, nécessite une attention toute particulière (90% du temps de réflexion doit être sur la création du modèle).
Anti-patterns au niveau de la modélisation :
- Avoir plus de 100k lignes par partition (100k de lignes est la valeur maximum recommandé)
- Avoir des partitions supérieur à 100Mb
- Trop de tables:
- Warning : si plus de 200 tables dans un cluster
- Echec : si plus de 500 tables
- Des Full scans / Cluster scans
- Les LightWeights transactions (4 fois plus lents en moyenne qu’une opération)
- Allow filtering (sauf si la requête utilise une seule partition)
- Utilisation massive ou récurrente des indexes secondaires
- Utiliser le type String pour représenter des dates et timestamps
- Ne pas avoir tester son modèle sur des données réelles avec une volumétrie similaire
- Utiliser le modèle read-before-write pour les transactions
- Abuser des opérations de « deletes »
- Utiliser des batchs qui requêtent multiples partitions
Au niveau du matériel :
- Utiliser des SAN / NAS
- Passer outre la configuration recommandée
- Ne pas désactiver le swap
- Ne pas désactiver CPU speed scaling
- Une liste est disponible sur : https://docs.datastax.com/en/dse/6.7/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Au niveau du driver JAVA :
- Redirigé en permanence les requêtes sur le même nœud coordinateur
Il s’agit bien sûr d’une liste non exhaustive, si vous souhaitez un audit ou une analyse de votre architecture ou modèle, n’hésitez pas à nous contacter.