Généralités
Ceci est le retour (personnel) de la présentation de Cassandra faite par Nicolas Romanetti.
Le point d’accroche de Cassandra est d’adresser les systèmes de volumétrie gigantesque en mettant en avant des capacités de montée ne charge aussi linéaires que possible en ajoutant des nœuds. L’ambition est de l’être pour l’écriture et pour la lecture (ce qui est une gageure sur de tels volumes).
Cette solution motorise certains des géants du Web, dont Twitter et Netflix, ce qui est probant quand on se penche sur la question des retours d’expérience. (Remarque : nous n’aurons pas les éléments dimensionnant des architectures en place).
Autres éléments distinctifs : la une solution est construite sans responsabilité maître-esclave à même d’encaisser les défauts d’un ou plusieurs nœuds.
Ce qui est structurant, comme pour un certain nombre de solutions NoSQL, c’est l’organisation des données en colonnes, elles-mêmes regroupées en Rows, elle-mêmes…. Le but est de proposer la possibilité :
- De changer sans aucune contrainte le « schéma » de la base de données,
- De se donner très peu de limites dans la quantité de données stockées.
Patterns de modélisation spécifiques :
- le nom est libre pour les colonnes : peut-être calculé dynamiquement ! (beaucoup utilisé pour des time series).
- on peut se passer de valeurs dans une colonne !
- on peut mettre deux notions dans un nom de colonne !
Tout peut avoir un sens quand on recherche la performance ultime.
Ensuite, le contenu d’une colonne peut être très diversifié, à l’exclusion de données binaires (pour des raisons d’engorgement mémoire et réseau) : XML, JSON , CSV…
On a également des briques qui serviront à la gestion des cycles de données (historisation, accès concurrentiel):
- Colonne expirante : suppression automatique ? Colonne compteur, Colonne Tombstone pour la suppression d’une valeur.
Cette souplesse se prolonge dans les environnements de production dont les modèles peuvent évoluer sans véritable contrainte (autre que la cohérence globale de l’application…bien entendu)
Partie II : les requêtes
Il nous est précisé que l’on ne requête pas de la même manière les lignes (ou ROW) courtes (Skinny) et longues (WIDE… avec des séries temporelles…à 10 millions de colonnes) :
- Sur les skinny rows : on effectue des requêtage en mode ‘tableau’
- pays [‘Thailande’][‘monnaie’]
- pays [‘Thailande’][‘population’]
- etc…
- Sur les Wide rows, on extrait des tranches (ou slices) : par exemple, la tranche des 100 derniers tweets d’un utilisateur.
En revanche, Cassandra ne dispose pas d’un arsenal de requêtage relationnel (oublier les GROUP BY…. )
Pour des usages spécifiques, on sera probablement amené à décliner les données selon plusieurs enregistrements (ou ROWS).
Partie III : l’architecture résiliante
La partie la plus conséquente de la présentation, et intéressante d’un point de vue des algorithmes entrant en jeu a été l’étude des mécanismes de cohérence de la base :
- Détermination du nombre de nœuds initial, avec possibilité d’en ajouter autant que nécessaire,
- Répartition uniforme des valeurs par hachage (token).
- Facteurs de réplication sur un certain nombre de nœuds avec des approches plus ou moins restrictives.
Les différents cas de mise en défaut d’un nœud (en écriture, en lecture) mettent en évidence la capacité de Cassandra à se régénérer presque automatiquement, en utilisant de façon soutenue les échanges entre nœuds (qu’ils soient en possession de la donnée, ou bien qu’ils jouent le rôle d’orchestrateur le temps d’une requête).
Une préoccupation doit toujours être à l’esprit du concepteur pour des raisons de performance: Les requêtes ne devraient pas solliciter plusieurs nœuds à la fois; On favorisera donc une architecture basée sur des ROWs de grande taille plutôt que sur une multiplicité de ROWs qui se retrouveraient distribués
Cassandra dispose nativement de 3 niveaux de ‘réparation’ ou de ‘remise en état’ des données incohérente qui donnent un niveau de fiabilité très important pour un système scalable.
Dernier point, les Performances.
Cassandra jouit d’une excellente réputation pour ses temps d’écriture, par le biais d’un mécanisme de CommitLog et de mise en mémoire rapide et sure.
Les transactions sont enregistrées en commitLog et mémoire pour pouvoir rejouer les requêtes le cas échéant. Elles sont ensuite prises en charge par un mécanisme de flush, puis suppression des données dans le commitLog.
Les Performances en lecture sont optimisées au travers des approches complémentaires suivantes :
- Accès direct en mémoire
- Row cache (sur les skinny rows),
- BloomFilter (Cf. WikiPedia)
- Et enfin du keyCache (sorte d’index des clés) en mémoire
- Et sur disque, de la compaction automatique
Nicolas Romanetti a fait un focus sur un point qui lui a paru nettement optimisable : la structure du code open source (et l’interdépendance des packages qui rendent peu lisible la responsabilité des composants).
Par ailleurs, les outils de monitoring semblent rudimentaires.
Et ensuite ?
Cassandra fait partie de la fondation Apache et connaît un développement soutenu, avec un certain nombre de fonctionnalités dans sa RoadMap (Intégration de Lucene pour les index secondaires, outillage, langage de requête CQL enrichi….).
Des efforts sont également faits pour utiliser Hadoop sur cette base, même si cette approche semble moins naturelle qu’avec HBase.
Est-ce pour cela que certains utilisateurs ont laissé de côté Cassandra ?
