Published by

Il y a 7 ans -

Temps de lecture 3 minutes

JCrete 2013 – Polyglot Data

java-specialists.jpg

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).

Published by

Publié par Pierre Laporte

Pierre est un touche-à-tout chez Xebia qui aime relever tous types de challenges. Des problématiques d'architecture aux tests de charge en passant par la gestion de dette technique ou encore les applications mobiles, c'est poussé par cette volonté d'apprendre qu'il oeuvre aujourd'hui chez Xebia. Il aime faire du code propre et expressif, apprécie le travail d'équipe et se concentre avant tout sur le service rendu à l'utilisateur final.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.