Il y a cinq ans de cela, alors que l’utilisation du terme NoSQL commençait à décoller et que beaucoup de bases de données NoSQL n’en étaient pas encore à leur version 1.0, il était courant, lorsque l’on était confronté au compromis formulé par le théorème CAP, de privilégier la disponibilité par rapport à la cohérence. ACID était délaissé, BASE représentait l’avenir.
Revenons rapidement au présent : la communauté a gagné en maturité, l’effet hype s’est tassé et de nouvelles bases supportant les transactions distribuées et tolérantes aux pannes entrent dans le jeu et redéfinissent nos attentes vis-à-vis des bases de données NoSQL.
La marche vers les transactions distribuées et tolérantes aux pannes a commencé fin 2012, quand Google a annoncé leur base Spanner. Spanner est une base de données transactionnelle, globalement distribuée et tolérante à la panne ; un ensemble de propriétés qui semblaient auparavant contradictoires. Google, en affirmant que leur produit tournait en production depuis plus d’un an, remettait alors en cause cette conception des choses.
Quelques mois après l’annonce de Google, l’équipe d’HyperDex annonçait discrètement leur add-on Warp, qui apporte à HyperDex la possibilité d’exécuter des transactions distribuées, tolérantes à la panne. Cela constitue la première implémentation open-source disponible de ce type de transactions. Le courant commence alors à s’inverser, mais il reste encore du chemin.
En mai 2013, Kyle Kingsbury a fait une présentation au sujet de Jepsen lors de la conférence RICON. Il a présenté toute une palette de faiblesses de différentes bases NoSQL confrontées à certaines conditions de défaillance. Même des bases comme MongoDB et Redis, toutes deux catégorisées comme bases de données consistantes, ont échoué à tenir leurs promesses.
Le travail de Kyle Kingsbury a poussé la communauté à se concentrer sur le test et la conception formelle et à mieux comprendre les compromis qu’implique le choix de la disponibilité par rapport à la consistance.
Au milieu de ces débats, FoundationDB sortait la version 1.0 de leur base clé-valeur, première base NoSQL propriétaire avec support des transactions distribuées, tolérantes à la panne. L’équipe FoundationDB a compris à ce moment la nécessité de rigueur dans les tests et s’est attachée à présenter, de façon passionnée, leur Framework de test, Lithium, qui leur a permis d’assurer les garanties ACID affichées. Ils ont pu plus tard exécuter Jepsen sans surprise.
Plus récemment, l’année 2014 a vu apparaître non pas une, mais deux bases de données NoSQL open-source conçues explicitement pour le support des transactions distribuées et tolérantes à la panne. Les travaux sur CockroachDB, qui essaie de reproduire le modèle de transactions géo-répliquées de Spanner, ont commencé au cours de cette année, alors que Treode livrait sa version 1.0 en juin. Ces deux projets prennent la conception formelle au sérieux et puisent dans un large ensemble de publications académiques sur les systèmes distribués.
L’impact de ces bases de données transactionnelles se ressent déjà dans le monde du NoSQL, où l’on observe la volonté des bases de données NoSQL consistantes d’améliorer leurs garanties. Par exemple, il y a une pression croissante sur Redis, qui construit ses capacités de distribution, pour accentuer le focus sur la conception formelle et le test.
Récemment encore, Tokutek a mis à disposition Ark, un nouvel algorithme de consensus pour MongoDB.
Bien qu’il soit encore tôt pour Treode et CockroachDB, il existe déjà plusieurs entreprises qui utilisent FoundationDB et HyperDex Warp en production. Les transactions distribuées tolérantes aux pannes sont là pour durer et nous pourrons prochainement constater leur impact dans ce paysage en forte évolution.