Les bases de données orientées colonnes forment une évolution du stockage clé-valeur différente de leurs cousines orientées documents. Il s’agit ici de représenter les données sous la forme de blocs de colonnes stockés de manière triée sur le disque. Bien que leur technologie soit encore peu maîtrisée, elles reviennent régulièrement dans l’actualité du fait des régulières annonces de migrations de quelques entreprises Web renommées. A ce titre, elles constituent la technologie la plus emblématique du mouvement NoSQL.
Cet article présente les principes des bases de données orientées colonnes, avant d’observer plus en détail Cassandra, un projet Apache se basant sur ce modèle. Ce projet a connu une croissance rapide qui lui a permis de sortir rapidement de l’incubateur Apache pour devenir un projet top-level.
Cette base de données avait initialement été créée par Facebook pour le stockage des messages (non instantanés) entre utilisateurs. Les ingénieurs qui en sont à l’origine avaient expliqué qu’il leur était possible d’accéder de manière très efficace aux messages échangés entre deux personnes ou aux messages contenant certains mots clés sur une base de données de taille conséquente. Cette performance est atteinte tout en assurant la réplication multi-datacenters. On comprend donc l’intérêt que peuvent y trouver les entreprises pour des cas d’utilisation forcément plus modestes.
Les bases de données orientées colonnes
Les principes du stockage orienté colonnes
Les bases de données orientées colonnes sont organisées en familles de colonnes (column family). Ce type de regroupement se rapproche du concept de table dans une base de données relationnelle.
Bien qu’elles soient organisées en tables, leur disposition est totalement différente. Ainsi alors que les colonnes d’une base de données relationnelle sont statiques et présentes pour chaque ligne, celles d’une base de données orientée colonnes sont dynamiques et présentes uniquement pour les lignes concernées. En d’autres termes, il est possible d’ajouter des colonnes à une ligne à tout moment et le coût de stockage d’un null est 0.
En fait, les bases de données orientées colonnes sont pensées pour accueillir un grand nombre de colonnes (jusqu’à plusieurs millions) pour chaque ligne. Dès lors on comprend qu’il ne s’agit plus simplement d’y stocker les champs d’une entité, mais également des relations one-to-many.
Les requêtes possibles sont simples. Il est possible de faire des requêtes par clé, ou ensemble de clés et d’y adjoindre un prédicat sur un intervalle de colonnes. Voici quelques exemples de requêtes possibles :
- Toutes les colonnes de la ligne dont la clé est
12 - Toutes les colonnes dont le nom est compris entre
"aaa"et"abb"pour la ligne dont la clé est156 - La colonne
"aaa"pour les lignes26à31
On dispose donc d’un système de requêtes minimaliste qui a permis de grandement simplifier le design de ces bases de données, au profit de la performance.
Cassandra offre une extension à ce modèle en proposant des super-colonnes qui se comportent comme des conteneurs de colonnes. Ceci ajoute donc une dimension supplémentaire au modèle permettant par exemple le stockage de listes de listes :
Il est alors possible de faire des requêtes qui portent sur un nom ou sur un intervalle de noms de super-colonnes permettant ainsi d’obtenir en retour une liste de super-colonnes et tout leur contenu.
Certaines bases de données (HBase actuellement, Cassandra prochainement) offre la possibilité d’ajouter un index secondaire sur des colonnes ; ceci permet alors d’utiliser la valeur d’une colonne indexée dans les requêtes.
Le fait que les colonnes soient stockées de manière triée sur le disque est un choix important puisque cela permet d’obtenir un intervalle de colonnes (ou de super-colonnes) avec un nombre réduit d’accès aléatoires sur le disque. Il nécessite par contre de reconstruire l’ensemble de la table de données sur le disque au fur et à mesure des modifications, ce qui est mis en œuvre de manière efficace dans HBase et Cassandra.
Quelques cas d’utilisation
La multiplication massive du nombre de colonnes rend ce modèle capable de stocker les relations one-to-many ce qui permet de couvrir de nombreux cas. En revanche les requêtes simplistes constituent une contrainte qui destinera les bases de données orientées colonnes aux applications pouvant se contenter d’accès aux données simplifiés au profit d’une performance, d’une scalabilité et/ou d’une fiabilité accrue.
Dans le monde du Web, les bases de données orientées colonnes permettront de supporter la montée en charge progressive sans pour autant sacrifier les fonctionnalités gourmandes en requêtes. Bien qu’elles aient été forgées par les « grands du Web » ces bases de données peuvent également être adaptées à d’autres types de systèmes.
Citons quelques exemples de cas d’utilisation de stockage :
- listes d’articles pour chaque utilisateur
- liste des actions effectuées par un utilisateur
- chronologie d’évènement maintenue et accédée en temps réel
- commandes en attentes (pour lesquelles le stockage de la liste des articles sera simple)
- données en masse à analyser
L’accès à ce type d’informations par page sera très rapide du fait de la co-localisation des données apportée par l’organisation des colonnes de manière triée sur le disque. Certains utilisateurs pourront se tourner vers ce type de bases de données pour profiter uniquement de leur modèle de distribution des données et les utiliser simplement comme stockage clé-valeur tout en conservant la possibilité d’une persistance de données plus riches à l’avenir.
La rupture avec les modélisations de données courantes
Cette organisation différente des données entraîne une véritable rupture avec les logiques de modélisations de données relationnelles, objets et hiérarchiques courantes. Les mailing-lists utilisateurs de Cassandra et HBase regorgent de questions portant sur cette problématique.
L’exemple le plus courant sur Cassandra est Twissandra, une modélisation de données pour une application clone de Twitter :
User = {
'a4a70900-24e1-11df-8924-001ff3591711': {
'id': 'a4a70900-24e1-11df-8924-001ff3591711',
'username': 'ericflo',
'password': '****',
},
}
Tweet = {
'7561a442-24e2-11df-8924-001ff3591711': {
'id': '89da3178-24e2-11df-8924-001ff3591711',
'user_id': 'a4a70900-24e1-11df-8924-001ff3591711',
'body': 'Trying out Twissandra. This is awesome!',
'_ts': '1267414173047880',
},
}
Timeline = {
# identifiant de l'utilisateur
'a4a70900-24e1-11df-8924-001ff3591711': {
# timestamp du tweet: tweet id
1267414247561777: '7561a442-24e2-11df-8924-001ff3591711',
1267414277402340: 'f0c8d718-24e2-11df-8924-001ff3591711',
1267414305866969: 'f9e6d804-24e2-11df-8924-001ff3591711',
1267414319522925: '02ccb5ec-24e3-11df-8924-001ff3591711',
},
}
User, Friends, Tweet et Timeline sont les familles de colonnes (column family). Des UUID sont systématiquement utilisés en tant qu’identifiants afin d’assurer leur unicité au sein du cluster. Les familles de colonnes User et Tweet sont simples et ne comportent qu’un ensemble fixe de champs. La famille Timeline comporte, pour chaque utilisateur, une liste d’identifiants de tweets triés par date. Ce tri est effectué naturellement par Cassandra puisque des timestamps sont utilisés en tant que noms de colonne. Cet exemple montre l’utilisation particulière des colonnes qui est faite dans Cassandra.
Cassandra
L’alliance de BigTable et de Dynamo
HBase et Cassandra s’inspirent tous deux de BigTable pour leur modèle de données orienté colonne et leur mécanisme de persistance sur disque. Si HBase s’inspire également de la publication de Google pour le reste de son architecture, Cassandra hérite de Dynamo le reste de ses propriétés. Cette publication d’Amazon définit un modèle de distribution peer-to-peer sans nœud master ni HDFS et ZooKeeper pour fonctionner.
Tour d’horizon de Cassandra
Pour ses accès disque, Cassandra privilégie toujours les accès séquentiels aux accès aléatoires, ce qui permet d’éviter une partie des latences importantes dues aux mécaniques des disques durs. Ainsi, lors d’une écriture, les données ne sont pas écrites directement sur disque mais stockées dans une table en mémoire ; un ajout dans un commitlog se comportant en append-only (et donc de manière séquentielle) permet d’assurer la durabilité de l’écriture. Lorsque la table en mémoire est pleine, elle est écrite sur le disque. Lorsque 4 tables ont été ainsi écrites sur disque, elles sont fusionnées en une table unique et la logique reprend du début.
Contrairement à Riak, Cassandra ne délègue pas à l’application la logique de résolution de conflit de version qui peuvent subvenir du fait du modèle de distribution utilisé. Lorsqu’un tel conflit se présente, Cassandra se base simplement sur le timestamp acollé à chaque colonne pour ne retenir que la version la plus récente.
Les clients communiquent avec Cassandra en utilisant des opérations exposées en Thrift, le protocole RPC léger développé par Facebook.
Premiers pas avec Cassandra
Après avoir téléchargé et installé Cassandra sur une machine, la première étape sera de configurer les répertoires de stockage des données et du commitlog. Ces paramètres sont à définir dans le fichier conf/storage-conf.xml :
<CommitLogDirectory>/var/cassandra/commitlog</CommitLogDirectory> <DataFileDirectories> <DataFileDirectory>/var/cassandra/data</DataFileDirectory> </DataFileDirectories>
Ce fichier de configuration permet également de définir les différentes column family. Par défaut le fichier contient une configuration mono-instance et un ensemble de column family d’exemple ce qui permet de faire les premières expérimentations. L’instance Cassandra peut être démarrée avec la commande :
bin/cassandra
L’utilisateur pourra alors lancer l’outil cassandra-cli qui permet d’interagir en ligne de commande avec une instance. Au sein de cet outil, la commande help montre l’ensemble des actions possibles et leur syntaxe. Ainsi, cassandra-cli permet de se familiariser avec Cassandra sans mettre œuvre un client Thrift en Java.
Cassandra en production
En production, Cassandra s’intègre parfaitement avec les solutions de monitoring habituelles en offrant de nombreuses métriques JMX. Clairement, l’outillage est pour l’heure très loin d’être aussi fourni que pour l’administration d’une base de données relationnelle. Cassandra offre malgré tout un certain nombre d’outils en ligne de commande qui permettront d’interagir avec les nœuds du cluster, pour forcer une opération de flush ou de fusion de tables sur disque par exemple.
Suite à l’ajout d’un nouveau nœud dans un cluster Cassandra, un temps non négligeable (plusieurs minutes selon le volume de données à transférer) sera nécessaire pour rééquilibrer le volume de données sur l’ensemble des nœuds.
L’avenir de Cassandra : une roadmap chargée
Cassandra a déjà connu de nombreuses améliorations depuis son introduction en tant que projet Apache. Sa roadmap reste pourtant chargée :
- Le support des vector clocks sera ajouté en version 0.7 pour permettre aux applications clientes de définir leur stratégie de résolution de conflits.
- La (re-)définition des familles de colonnes dynamiquement sera possible à partir de la version 0.7 et permettra d’éviter leur configuration dans le fichier
storage-conf.xml. - Le support d’Avro, en complément de Thrift, sera apporté en version 0.7 pour palier aux problématiques récurrentes liées à Thrift.
- Le format des tables sur le disque évoluera en version 0.8 pour permettre l’implémentation des indexes secondaires et améliorer les performances.
- Les indexes secondaires, permettant de formuler des requêtes qui portent sur la valeur d’une colonne, seront disponibles dans la version 0.8
Conclusion
Si Cassandra et HBase appartiennent à une famille de base de données très prometteuses, elles sont également les plus délicates à appréhender de part leur mode de distribution et leur modèle de données non familier.
Malgré tout, les communautés très actives dont ces deux projets bénéficient (surtout celle de Cassandra) s’attachent à établir un ensemble de bonnes pratiques et à créer les outils nécessaires pour faciliter l’utilisation de ce nouveau mode de persistance. En outre, le fait que Jonathan Ellis (Project Leader de Cassandra) vienne de créer sa propre entreprise dédiée exclusivement à l’expertise Cassandra est un signe fort du potentiel de cette technologie.
