Harry Potter, voldemort, SimpleDB ??? vous devez vous dire que ca y est, il a craqué…
En fait nous avions déjà évoqué Voldemort lors d’un précédent article sur les alternatives aux bases de données relationnelles.

Voldemort est une alternative aux systèmes internes d’Amazon Dynamo. Disponible en Open Source, cette solution implémente les mêmes patterns que Dynamo et est utilisée par LinkedIn.

Patterns mis en œuvre

Les grands du web ont développé, sous des contraintes de charge, des systèmes de stockage innovants. « Contraints » de partionner la donnée et de respecter le théorème de CAP, qui impose de choisir entre disponibilité et consistance, certains de ces acteurs comme Amazon ont choisi la disponibilité de leur système de stockage et proposent un modèle clé/valeur éventuellement consistant.
La disponibilité du système tout d’abord avec la mise en œuvre des principes suivants :

• un mode master/master. Tous les nœuds sont disponibles en écriture. Un mécanisme de répartition de charge permet de dispatcher l’ensemble des requêtes sur l’ensemble des nœuds. L’utilisation de l’algorithme Vector Clock permet de suivre et de conserver les différentes versions ainsi que l’historique des objets notamment dans le cas d’écriture sur différent nœuds « master ». Des échanges protocolaires (type « gossip protocol ») permettent de propager de l’information (serveur perdu…)
• Partitionnement et réplication automatique des données entre les différents serveurs qui composent le cluster de base avec des enjeux d’optimisation des coûts (« commidity hardware ») et de résilience des systèmes. Le consistent hash est utilisé pour la répartition des clés sur les nœuds. Cet algorithme avait été présenté dans le cas de memcached comme un moyen de limiter la perte d’un cache. Dans une solution comme Voldemort, la donnée est persistante et cet algorithme permet de limiter la quantité de données à redispatcher sur les nœuds restants (pour respecter les configurations de réplication, de consistance).
• Un modèle éventuellement consistant qui cherche une alternative à ACID et au Two Phase Commit. Dans cette approche, toutes les versions des objets sont écrites (l’historique est géré par le « Vector Clock »), les conflits éventuels sont détectés et gérés au moment de la lecture de l’objet : mode « Read-Repair ». La réconciliation des objets se fait à la lecture en se basant sur les informations contenues dans le « Vector Clock ». La consistance quand à elle est garantie par le nombre de serveurs possédant la même version de cette donnée. En fait la consistance peut être paramétrée, c’est-à-dire qu’il est possible de définir, type de données par type de données, le nombre de nœuds sur lesquels une donnée doit être écrite pour considérer une écriture valide ou bien (plus intéressant) le nombre de nœuds sur lesquels une donnée doit être lue pour être considérée comme consistante. La configuration fine qu’il est possible de réaliser sur la donnée (nombre de nœuds en réplication….) permet d’adapter l’utilisation de l’espace de stockage à la criticité de la consistance en fonction des cas d’utilisation.

Mais rentrons dans le vif du sujet et regardons d’un peu plus près une solution comme Voldemort.

Stockage de l’information : structure, insertion et récupération des données

Une première étape simpliste consiste à définir la classe que l’on souhaite stocker. Exemple également classique : considérons un objet Client qui propose 3 propriétés que sont son identifiant (key), son nom (lastName) et son prénom (firstName). Les trois propriétés sont de simples chaînes de caractères.
Pour stocker cette classe, il vous faudra définir son schéma, c’est-à-dire la liste des attributs qui la compose. Voldemort propose plusieurs façons de stocker l’information ; sur ce coup, j’ai utilisé JSON. Ainsi, il vous faudra modifier un fichier de configuration (store.xml) pour rajouter le schéma suivant :

1
2
3
4

…
 
json
{"key":"string", "firstName":"string"...}

Le truc intéressant est que chaque schéma est versionné . Il est ainsi possible d’avoir plusieurs versions et donc plusieurs structures d’un même type de donnée (dans notre exemple Client). Ainsi, à l’insertion, le moteur utilisera la dernière version définie. A la lecture, le moteur utilisera la version adéquate.
Vous aurez également noté l’absence complète de contrainte d’intégrité. Autant de vérification qu’il faut reporter et réaliser au niveau de l’espace applicatif.
Voldemort propose la notion de Store pour le stockage de ces données. A chaque Store est associé un type de donnée (défini comme précédemment).

1
2
3
4
5
6
7
8
9
10

int numThreads = 10;
int maxQueuedRequests = 10;
 
int maxConnectionsPerNode = 10;
int maxTotalConnections = 100;
String bootstrapUrl = "tcp://10.1.100.196:6666";
 
StoreClientFactory factory = new SocketStoreClientFactory(numThreads, numThreads, maxQueuedRequests, maxConnectionsPerNode, maxTotalConnections, bootstrapUrl);
 
StoreClient< string , Object> client = factory.getStoreClient("author");

Dans notre traditionnel monde relationnel, un store serait comparable à une table. SimpleDB propose un concept similaire avec la notion de « Domain »
Insérer, supprimer ou récupérer des données est on ne peut plus simple. L’API proposée est en effet assez légère et proche de celle d’une Map. Autrement dit, insérer un objet se fait de la sorte (on note quelques similitudes avec les APIs Java permettant d’accéder à SimpleDB et l’utilisation d’une Map et non pas d’un objet Java pour insérer les attributs)

1
2
3
4
5
6

Map< string , Object> authorMap = new HashMap< string , Object>();
authorMap.put("key", "aKey”);
authorMap.put("firstName", "Bret Easton”);
authorMap.put("lastName", "Ellis”);
 
client.put("aKey”, authorMap);

Récupérer un objet est encore plus simple :

1

Versioned< object> object = client.get("key1");

En fait, le plus complexe résidera dans la génération (intelligente) de la clé (comment assurer l’unicité ? comment la retrouver ?…)

Réplication et « fail-over »

Gérer le « fail-over » se fait en répliquant la donnée sur autant de machines que nécessaire. Voldemort permet de spécifier ce paramètre dans le fichier de configuration store.xml via l’élement replication-factor. Si la valeur vaut 1, la donnée n’est répliquée sur aucun nœud et en cas de perte du serveur, vos données sont perdues. Sinon, la donnée associée au « store » est répliquée sur autant de nœud que défini.

Les données sont alors réparties en respectant les principes de « consistent hashing » ce qui limite la masse des données à redéployer en cas de perte d’un des serveurs.

Réplication et consistance

Assurer la consistance…Tout un programme dans un modèle « éventuellement consistant »…Contrairement à ACID qui isole, verrouille certaines portions de données, et quelque part séquence les transactions les unes à la suite des autres, ces modèles ont fait le choix de la disponibilité à l’écriture et les éventuelles divergences (et réconciliation) entre données sont gérées à la lecture (mode « Read-Repair »). Comme évoqué précédemment, il est possible de configurer le nombre de nœuds sur lequel la donnée doit être répliquée pour considérer une écriture valide ( W ) ainsi que le nombre de nœuds sur lequel la donnée doit être lue (R) pour être considérée comme consistante. Si de plus, votre configuration respecte la formule magique W+R > N, N étant le nombre total de nœuds sur lesquels la donnée est répliquée, vous êtes dans un modèle consistant : une lecture suivant immédiatement une écriture est garantie de retourner la dernière valeur écrite.
Cette configuration se fait au niveau de chacun des « Store ».

Définition du cluster de base

L’architecture physique ci-dessus se définit au niveau de Voldemort dont voici un extrait de la configuration :

< cluster >
	< name >mycluster< /name >
	< server >
		< id>0< /id>
		< host>10.1.100.196< /host>
		< http-port>8081< /http-port>
		< socket-port>6666< /socket-port>
…

	< server>
		< id>1< /id>
		< host>10.1.100.196< /host>
		< http-port>8082< /http-port>
		< socket-port>6667< /socket-port>
…
…

Configuration de la réplication

Au niveau des fichiers store.xml, les paramètres de réplication, nombre de lectures ou d’écritures nécessaires pour garantir la consistance, sont définis :

< store>
    < name>author< /name>
    < persistence>bdb< /persistence>
    < routing>client< /routing>
    < replication-factor>2< /replication-factor>
    < required-reads>1< /required-reads>
    < required-writes>2< /required-writes>
…

…

Gestion de la réplication – le test.

Le meilleur moyen de tester la réplication reste de se connecter sur un des nœuds du cluster (hyper simple en ligne de commande) et de localiser la donnée (Voldemort fournit des fonctions permettant – à la sqlplus – de naviguer dans les données)

L’écriture de la donnée pour la clé « key9999 » a été dupliquée sur deux nœuds. La lecture de la donnée donne :

Gestion de la réplication – autre test…

En modifiant légèrement la configuration (en imposant 2) et en arrêtant certaines instances (notamment celles, sauf une, qui contiennent la donnée), la lecture de l’objet est impossible : seul un serveur contient la donnée et la configuration en attend deux…

1
2
3
4

> get "key1"
: GET operation on store 'author' completed unsuccessfully in 1.98 ms.
Could not connect to node 3 at 10.1.100.196 marking as unavailable for 2000 ms.
voldemort.store.UnreachableStoreException: Failure while checking out socket for 10.1.100.196:6669:

Conclusion

Difficile de conclure une introduction ou un tutorial sur un produit mais deux choses m’ont surpris lors de l’utilisation (en mode POC) de ce produit.

Premièrement, sa simplicité d’installation et d’utilisation. Je n’ai aucune expertise de type « administration des bases de données relationnelles » et certes, ce tutorial reste du niveau introduction et ne fait pas mention des problématiques de la « vraie vie » : celles de la production. Il n’empêche que de prime abord, c’est simple et intuitif.

En second lieu, sa possibilité de « tuning » fin au travers notamment des paramètres de réplication, et un aspect que nous n’avons pas abordé : la notion de partition (les données sont associées à des partitions et il est possible de répartir les partitions sur des serveurs physiques différents – par configuration malheureusement – entre les serveurs physique des bases). Ce « tuning » fin permet d’optimiser l’utilisation de l’espace de stockage en l’adaptant au cas d’utilisation (plutôt orienté lecture ou écriture) et aux types de données (ceux qui nécessitent une forte consistance etc…) ; bref de placer, sur des systèmes fortement sollicités, le curseur entre consistance et performance.

D’autres points surprennent. La définition des structures des données (au format JSON dans notre exemple) me laisse songeur quant à la gestion des champs obligatoires. Bien entendu la gestion des relations (ou plutôt son absence) imposera soit de dénormaliser le modèle soit de gérer les relations sous la forme d’identifiant simple (en stockant simplement l’identifiant de la donnée référencée). Enfin l’absence de langage de requêtage pose des questionnements quand à la faculté de retrouver la donnée une fois stockée, sauf à utiliser des recherches « full-text » : un autre bel enjeu d’architecture.

Suggestion d'articles :

1. no:sql(eu) et NoSQL : qu’en est il?
2. Des alternatives aux bases de données relationnelles…
3. Panorama des différentes offres de cloud computing : Amazon Web Services

L’avènement du Cloud et la transparence (maitrisée) de ses acteurs nous permet de découvrir quelques-uns systèmes mis en œuvre chez des acteurs comme Amazon ou Google. Les offres de type SimpleDB, Google Data Store nous font certes rêver mais permettent également de découvrir des solutions utilisées en interne des grands sites web avec par exemple la BigTable du côté de Google ou bien Dynamo du côté d’Amazon.

Ces systèmes innovants ont été développés sur mesure pour répondre à des enjeux de charge quasi hors normes (à titre d’exemple, pour eBay, on parlait il y a quelques années de 1 milliard de pages vues et de 44 milliards de requêtes par jour) tout en étant fortement adaptés aux spécificités de chacune de ces plateformes et de leur utilisation : Amazon et eBay – avec des notions de stock, facturation, consultations et recherches de produits… – utilisant leur espace de stockage de façon différente de Google – qui propose un moteur de recherche – .

Ainsi et sous ces contraintes, ces systèmes n’ont eu d’autres choix que d’évoluer, d’innover et ces acteurs ont investi et développé des espaces de stockage surprenants et en rupture avec nos modèles de stockage relationnel : de « simples » structures distribuées dans lesquelles la donnée est globalement stockée sous la forme clé/valeur. Mais des systèmes équivalents ou du moins proposant des concepts similaires sont également disponibles sous la forme d’outils Open Source que l’on peut déployer dans nos SI.

« BigTable-like systems » ou une vision multidimensionnelle de l’espace de stockage : l’approche Google

Les systèmes de type « Big Table » également nommés « Column Oriented DataBase » permettent d’avoir plusieurs dimensions de stockage et d’analyse de la donnée tout en répartissant le stockage sur plusieurs machines. A titre d’exemple, BigTable peut être vue comme un map multi-dimensionnelle

Source : http://labs.google.com/papers/bigtable.html

Une première dimension correspond à la ligne. Cette ligne est identifiée dans notre exemple par la clé com.cnn.www et l’ensemble des clés est trié par ordre lexicographique. Ainsi, le contenu associé aux clés les plus proches (ex. com.cnn.topics et com.cnn.www dans notre exemple) est regroupé. Les lignes sont ensuite regroupées en « tablets » qui sont une unité de répartition. La seconde dimension qui correspond aux colonnes (qui peuvent être regroupées en famille de colonnes) représente un autre axe de lecture (également indexé). Par exemple, le ou les langages dans lesquels la page a été écrite, les pages référençant l’élément courant (l’élément « anchor » dans notre exemple).

Le monde open source n’est pas en reste avec des alternatives comme (sans être exhaustif) HBase (en relation avec le moteur Map-Reduce Hadoop intégré chez AWS) ou Hypertable qui se veut une implémentation de la BigTable de Google.

Quand au monde du Cloud, Google offre son service de stockage BigTable au travers de leur Google DataStore. Un modèle non relationnel qui demande de prendre en compte les quelques éléments suivants :

• Google Data Store offre un modèle « fortement consistent » et se base sur un mode de concurrence optimiste; ie. pendant qu’une application met à jour la donnée, les autres mises à jour échouent immédiatement
• Chaque entité est représentée par une liste de propriétés qui peuvent être optionnelles et multi-valuées. Les entités sont regroupées au sein d’« entity group » et les entités peuvent être reliées entre elles dans un mode parent-child ; ce qui offre une modélisation hiérarchique.
• La gestion des transactions est assurée. Une limite tout de même puisque la transaction ne peut être garantie que sur un « entity group »
• La gestion des relations est supportée et distingue deux cas : (1) le cas « owned relationship » où les objets ne peuvent pas vivre l’un sans l’autre (une composition au sens UML) et où ces derniers seront stockés dans le même « entity group » et (2) le cas « unowned relationship » qui permet de référencer des objets d’autres « entity group ».
• Le dataStore de Google est accessible via JPA ou JDO (avec quelques subtilités néanmoins…)

« Key-value Stores » : l’approche Amazon

Sur un modèle plus simple à appréhender que le modèle précédent, ce type d’espace de stockage permet de voir les objets sous la forme de clé/valeur et de stocker, telles quelles (sous une forme binaire ou textuelle suivant les cas et les implémentations) et donc selon une dimension (la clé) les « instances ».
Cette catégorie est riche de prétendants et l’on peut ainsi noter :

• Tokyo Cabinet dont la blogosphère parle de plus en plus et qui propose différents produits, une base de données key/value, un moteur de recherche full text et une partie (Tyrant) permettant la réplication entre serveurs et accessibilité via le protocole memcached et http.
• Cassandra qui est utilisé par Facebook.
• Simple DB. Simple DB est la réponse d’Amazon en termes de solution de stockage à forte scalabilité. A l’instar du Google Data Store, SimpleDB modélise ces entités en « Domain ». Chaque « Domain » est constitué de « Data Item » (que l’on peut apparenter à une ligne dans le monde relationnel) et chaque « Data Item » est composé d’un ensemble d’attributs (assimilable à une colonne d’une table dans les bases relationnelles). Une certaine souplesse est possible au niveau du schéma ce qui permet de stocker tout ou partie des propriétés, mais sous forme de chaîne de caractère uniquement.
• Voldemort : l’alternative Open Source. Il est difficile de savoir si SimpleDB est construit sur le système de stockage interne Amazon Dynamo mais dans l’hypothèse où ces alternatives vous fassent rêver au point ou vous voudriez un tel espace de stockage chez vous (déjà, appelez moi parce que ca me brancherait bien de bosser avec vous sur le sujet…), Voldemort est une alternative sérieuse. Cette solution dont le nom s’inspire peut-être (je n’ai pas su percer ce mystère) de la saga Harry Potter, est utilisée chez LinkedIn.

Mais les approches types SimpleDB et Voldemort se différencient de l’approche choisie par Google car. Tout d’abord, (1) ces solutions proposent un modèle éventuellement consistent . Autrement dit, ces systèmes sont architecturés pour garantir de bonnes performances en écriture (il faut que le client puisse valider sa commande le plus rapidement possible, quelques soient les pannes) sur des systèmes soumis aux charges évoquées précédemment, la réconciliation se faisant au moment de la lecture (mode « Read-Repair »). Il y a deux « inconvénients » ou plus exactement changement de « mindset » liés à cette approche. Le premier est le risque (ou la quasi certitude) d’avoir plusieurs versions du même objet. Le second est de ne pas garantir qu’une lecture consécutive à la mise à jour d’une donnée retourne la donnée à jour (d’où le caractère « éventuel » de la consistance). Ensuite (2) l’absence de gestion d’atomicité des opérations (et donc par extension de transaction). Enfin (3), SimpleDB est accessible par des APIs type REST ou SOAP (même s’il existe des Apis client Java masquant les accès ).

Des modèles non relationnels qui posent de nouveaux de nouvelles contraintes

Ces approches proposent un modèle moins structuré et bien entendu non relationnel. Des alternatives qui soulèvent de nouveaux points d’attention.
Au niveau des développements tout d’abord :

• Là ou le modèle relationnel cherche à normaliser la donnée pour éviter duplication et faciliter la gestion des relations entre entités, le modèle clé/valeur n’offre rien. Autrement dit, les relations entre entités ne sont pas (ou peu) gérées – explicitement par le moteur de base – et rien n’exclut les possibles doublons de données. Autrement dit, impossible de s’appuyer sur le moteur pour garantir l’intégrité de la donnée ; il vous faudra la gérer au niveau de l’espace applicatif
• En terme d’API, le modèle clé/valeur est ultra simpliste puisqu’il ne propose pas d’équivalent au langage SQL. Ainsi les seules APIs dont vous disposerez sont PUT, GET, DELETE et les recherches multicritères seront à remplacer – ce n’est pas anodin en terme d’architecture – par des recherches « full-text ». Au mieux vous disposerez de quelques possibilités de filtres sur les valeurs des champs (par exemple = ; != < …). De même, pour les notions de jointures, triggers, procédures stockées…tout remonte dans l’espace applicatif avec comme impact sur les architectures une orientation vers plus d’évènementiel
• Quid de la génération des clés. En effet, tout est clé mais ces systèmes ne mettent à disposition aucun mécanismes de génération de clé…Au revoir belles séquences, bonjour service de génération d’identifiants.

Au niveau de l’administration des bases ensuite :

• Concernant les migrations de données. Ces solutions (sauf erreur de ma part) ne proposent pas de fonctionnalités d’extraction et la migration d’un système à un autre risque de ne pas être évidente. Cela risque d’être d’autant moins évident que sans parler de standard, SQL est supporté par l’ensemble des éditeurs (avec certes des limites, des fonctions spécifiques…). Ce n’est pas le cas de ces solutions qui ne partagent pas de « socle commun ».
• Gestion des backups. Là encore (et sauf erreur de ma part), ces solutions divergent de nos traditionnelles bases de données relationnelles en ne proposant, « out-of-the-box » , aucun mécanisme de backup. Pour les services Cloud fournis (type SimpleDB ou DataStore), on peut imaginer que le « provider » est garant de la réplication des données (entre Data Center ou « availability zone » notamment). Pour des solutions utilisables en interne et même si cela dépend des implémentations, il est possible de paramétrer différents moteur relationnel (BDB, MySQL…) pour le stockage physique de la donnée. On peut donc imaginer utiliser les mécanismes de backups classiques (la contrainte devenant le nombre d’instances qu’il faut « backuper »)

Mais paradoxalement, ces contraintes sur le modèle de données me semblent avoir des vertus sur les architectures applicatives. Nous l’avons évoqué à maintes reprises mais tous les objets sont identifiables par une clé et les seules APIs disponibles sont PUT/GET/DELETE. Pas très loin de certains préceptes REST en quelques sortes. Des contraintes qui finalement auront pour bénéfices de rendre vos services ultra –simples et limpides :

• Les signatures vont se limiter à un paramètre qui est l’identifiant de l’objet.
• L’absence de requêtes complexes qui imposera des recherches « full-text » va simplifier encore les signatures de services de recherches (plus de multi-critères qui évoluent dans le temps…).
• Des possibilités de versionning plus simple puisque la signature sera identique

De même, là ou le modèle relationnel impose un certain niveau de modélisation des concepts métiers, niveau de modélisation qui a permis à certains systèmes de partager l’espace de données, l’approche clé/valeur va pousser au développement d’un émissaire (APIs de service) visant à encapsuler un Domain Model propre et un minimum partageable (ie. pas trop adapté à une application unique), bref à vous mettre dans une dynamique de services pour conserver un minimum de maitrise sur ce modèle de données.

Pour conclure…

Il est intéressant de constater que ce type de stockage nous met d’office dans un modèle non relationnel : ce à quoi on arrive (dans une moindre mesure) lorsqu’on cherche à optimiser les performances d’une application (et notamment de ses requêtes). Cette dénormalisation à outrance imposée par ces systèmes permet d’avoir des requêtes efficaces, faciliterait le partitionnement et la réplication de la donnée au travers d’une ferme de serveurs de bases de données.

Remarquons néanmoins que nous utilisons déjà des systèmes non relationnels. Nos systèmes traditionnels mettent assez rapidement et systématiquement en œuvre des caches au dessus des modèles relationnels ; des solutions qui visent à optimiser les temps de réponse (a minima en lecture) et qui se limitent, au final, à un système de stockage clé/valeur.

Dès lors se pose la terrible question : « à quel moment faut-il se passer d’un modèle relationnel ? ». Difficile art que d’y répondre en ces quelques lignes mais l’on peut déjà noter les éléments suivants :

• Les niveaux importants de charge auxquels sont soumis les systèmes. Typiquement si vos systèmes tapent des limites en écriture, ont déjà mis en œuvre des mécanismes de réplication master/slave pour soulager le master des lectures, ce sont peut-être des alternatives à étudier et qui vous permettrons de dépasser vos limites de scalabilité tout en tentant de maîtriser vos coûts
• Les autres axes différentiants sont liés aux niveaux de relationnel du modèle. Par exemple un modèle en forme d’arbre ou qui propose énormément de relation many-to-many sera difficile à dénormaliser. A l’inverse, certaines applications se contentent se stocker de l’information non structurée (les dernières versions d’Oracle propose le type XML Type permettant de stocker des valeurs de types XML…). Ou encore dans le cas de certains cas d’utilisation (typiquement des Batchs) où des tables de travail et la dénormalisation sont souvent mises en œuvre.
• Enfin, le « confort des développements » et dans ce cadre, il s’agira de savoir jusqu’à quel point vous souhaitez vous appuyez sur la base de données pour gérer tout ce qui est contraintes d’intégrité, les mécanismes de backup…

Et puis se limiter aux approches « clé/valeur », c’est oublier d’autres types de base de données comme les systèmes orientés document qui permettent de stocker des informations structurées et offrent des fonctionnalités de requêtages plus riches (Base XML, Mongo DB ou bien encore les systèmes orientés graphe comme Neo4j qui sont à l’inverse optimisés pour des modèles hyper hiérarchiques…

Je reste néanmoins intimement convaincu que ces systèmes offrent de vraies alternatives à ce que nous connaissons. Mais dire que la migration sera simple serait mentir. C’est tout un univers qui s’ouvre, des compétences à développer, des limites et des cas d’usages à trouver. Puis comme dirait l’autre, vous n’avez peut-être pas de problèmes avec vos bases de données relationnelles. Alors pourquoi migrer ?
A défaut de trouver ces solutions dans nos systèmes, les connaitre ne peut que nous nous aider à mieux utiliser les offres de stockage du Cloud comme SimpleDB ou Google Data Store et ainsi mieux comprendre les limitations et les impacts sur les architectures applicatives. Bref, un beau challenge…

Addendum : A peine ce document rédigé que Amazon annoncait son service RDS : une base de données relationnelle (mySQL) avec la possibilité de scalabilité verticale (AWS propose différente puissance de machines). Dans tous les cas, un service pertinent qui limitera fortement l’adhérence aux services spécifiques du providers.

Suggestion d'articles :

1. Industrialisation des développements : automatisez votre base de données
2. Une base de données purement fonctionnelle
3. Outiller un audit de base de données