JCrete 2013 – Polyglot Data

Chris Richardson nous a proposé une réflexion sur les systèmes utilisant plusieurs types de bases de données.

Les sessions ont toutes été enregistrées (audio seulement) et seront publiées sur le site WikiEducator à l’adresse : http://wikieducator.org/index.php?title=JCrete2013:Blog

Rickard Öberg nous a expliqué utiliser plusieurs types différents de bases de données en production sans problèmes. Pour cela, ils ont mis en place une architecture CQRS avec un type de base de données pour un set de use-cases précis :

• Une base de données pour les events au format brut (fichier),
• une base de données clé-valeur pour les snapshots,
• Une base de données MySQL pour le reporting.

Martin Thompson souligne que la technique d’event sourcing, bien qu’à la mode en ce moment, n’est pas nouvelle. Elle est utilisée depuis plus de 30 ans, notamment dans les systèmes à base de transactions journalisées.

Dans un système polyglotte, les types de bases de données utilisées ont l’une des caractéristiques suivantes :

• High-mutation datastore – lorsque les données évoluent,
• Low-mutation datastore – ou base de données "Append only",
• Reporting store.

C’est typiquement le modèle auquel eBay est parvenu, en utilisant avant l’heure l’architecture CQRS :

• le modèle est "Eventually consistent" entre les datastores,
• le catalogue produit est découpé en catégories, avec une ou plusieurs catégories par cluster de datastore,
• dans un cluster de datastore, un noeud est optimisé pour l’écriture, les autres sont optimisés pour la lecture.

Parmi les problèmes fréquemment rencontrés figure celui des données incohérentes. Ces situations ne peuvent être que rarement évitées et donc il est préférable de s’y préparer, par exemple en :

• Implémentant une machine à état décrivant le statut de la donnée,
• Concevant le modèle pour que les données soient toujours écrites dans le même ordre et ne les rendre utilisables qu’en dernière étape du traitement. De fait, les données transitoires ne sont pas considérées comme exploitables par le système.

Il y a aussi le problème des migrations de ces données. Les bases NoSQL supportent très bien les changements simples de schéma, mais lors de migration plus complexes, pour éviter le downtime, on peut utiliser la technique de "lazy-migration" : à la consultation d’une donnée, le système procède à sa migration si cela n’a pas déjà été effectué. Ce mécanisme est similaire à celui du "self-healing" dans lequel les données ne sont corrigées que lorsqu’elles sont accédées.

Enfin, lorsque l’on envisage d’introduire un nouveau type de base de données, il faut que la prise en main soit très rapide, afin de :

• pouvoir rapidement se rendre compte si c’est une erreur et faire marchine arrière, le cas échéant,
• pouvoir rapidement passer en production et avoir un TTM très bas.

En résumé, une architecture polyglot-data, c’est :

• Avoir un datastore avec lequel on est efficace et qui supporte une mutation fréquente du modèle de données,
• Avoir un autre datastore qui supporte efficacement le stockage du modèle une fois les données figées,
• Avoir un autre datastore qui supporte efficacement le requêtage du modèle (pour le reporting, par exemple).