Les bases de données modernes doivent répondre à un triple défi : celui des volumes, synonyme de Big Data, celui de l’évolutivité (scalability) et celui de la compatibilité SQL. Le tout, sous couvert du bon vieux néologisme ACID.

Les défis imposés par les applications modernes, induisent de faire appel à des architectures clusterisées pour porter le code et les données des transactions. Le mode « scale-out » est cette capacité essentielle qui permet de faire évoluer l’infrastructure de manière horizontale, sans intervention manuelle de la part des utilisateurs.

C’est un aspect fondamental des bases de données en clusters, qui ne doit pas pour autant fragiliser l’équilibre des données opérationnelles et remettre en cause la fameuse « consistance », ce critère qui veut que les données, même réparties dans un cluster, sont laissées dans un état cohérent, après avoir été manipulées par une transaction (le C de ACID).

Aspect important, donc, mais difficile à garantir avec des méthodes traditionnelles.

2017 aura été de ce point de vue, une très intéressante année, puisque plusieurs databases en clusters ont été annoncées, qui justement font de cette consistance, un élément clé de leur stratégie : d’abord Spanner chez Google, un système déjà testé en interne depuis plusieurs années, mais aussi CockroachDB, ClustrixDB, etc, venus rejoindre Azure SQL Database, la solution Microsoft du Cloud Azure.

Distribution dans un cluster

Jusqu’à présent, quand il fallait traiter le problème de l’évolutivité de la base de données, autrement dit son adéquation aux volumes, on avait plutôt tendance à abandonner le mode relationnel ACID et passer au paradigme NoSQL CAP. CAP n’ayant rien à voir avec ACID et Brewer ayant démontré qu’aucune base NoSQL ne respecte les trois branches du modèle. La base sous-jacente étant généralement de type clé-valeur, la consistance n’est pas correctement pris en compte et les architectes ont soit dû développer du code au-dessus du SGBD, soit passer par des produits tiers, pour en garantir le respect.

Il faut croire que le problème était devenu important, car le marché s’est mis à bouger, avec quelques grands noms, Google et Microsoft, pour ne citer que les plus importants.

Spanner de Google est un service de gestion de données réparties dans un cluster, qui remonte à février 2017, dont l’une des qualités est de garantir la consistance des données, après le « passage » des transactions. Chaque instance Spanner peut être portée par une machine unique, dans le Cloud Google, ou au contraire être répartie sur plusieurs machines, selon le volume des données et la charge transactionnelle.

Pour garantir la disponibilité des données, en dépit des pannes, les données sont répliquées dans des domaines différents et ce, de manière transparente pour les utilisateurs.

Les données et transactions de Spanner bénéficient d’une disposition toute particulière de Google, TrueTime, un système d’horodatage, qui lui permet d’attribuer une date et une heure à chaque transaction et bloc de données, Spanner apparaissant au fond, grâce à TrueTime, comme une sorte d’organisation séquentielle, même si les données sont réparties dans un cluster. Il ne peut y avoir, a priori, de confusion et chaque transaction et donnée, appartient à une chronologie sans faille, ni doublon.

TrueTime a un temps d’exécution très rapide de sept ms, très loin devant les autres mécanismes d’horodatage, tels que NTP qui ne peuvent pas agir en moins de 150 à 200 ms. C’est grâce à cette rapidité, que chaque donnée peut être estampillée de manière unique, sans confusion avec les autres.

Une discrimination temporelle, que Google a pu exploiter pour faire en sorte que non seulement la base puisse évoluer de manière automatique en termes de volumes, mais aussi de consistance.

L’inconvénient avec Spanner est qu’il ne respecte pas totalement la syntaxe SQL et comporte des objets SQL spécifiques de « consistance externe ».

Sans oublier le fait que l’on est dans le Cloud de Google, ce qui pour certains utilisateurs peut constituer un blocage rédhibitoire…

Des nouveaux-venus

D’autres éditeurs se sont intéressés au sujet, tels que CockroachDB, une solution Open Source, qui répond aux mêmes besoins de « scalability », mais avec une meilleure compatibilité SQL, en particulier pour les jointures, les contraintes de clés étrangères et la consistance transactionnelle. Ce qui ne l’empêche pas d’ajouter ses propres objets.

Au-delà de la consistance, CockroachDB est annoncé comme strictement compatible ACID et il traite par exemple l’isolation en deux niveaux : SERIALIZABLE et SNAPSHOT, ce qui n’est pas courant.

Evidemment, CockroachDB ce n’est pas Google, ni même Microsoft. C’est une petite structure qui certes, propose une solution techniquement intéressante, mais pour laquelle il conviendra de mesurer soigneusement la crédibilité. D’autant que comme c’est souvent le cas, la compagnie a pour vocation d’être rachetée…

En attendant elle participe au débat, apporte des idées neuves, ce qui n’est déjà pas si mal…