MongoDB épingle un contrat de confiance ACID à sa base NoSQL
La base de données annonce le support de garanties ACID pour les transactions multi-documents. La société se positionne sur les terres historiques des bases relationnelles et veut devenir une base généraliste.
MongoDB ne veut plus être aux côtés des bases de données relationnelles. Il veut purement les remplacer. L’un des pure-players des bases de données dites NoSQL (pour Not Only SQL) a annoncé ce jour virer complétement ACID et supporter ainsi le monde transactionnel dans sa globalité. Empiétant directement sur les terres des bases relationnelles historiques avec qui il faisait pourtant bon ménage dans les SI des entreprises. D’ailleurs, le message de MongoDB est désormais clair : Il n’est plus une seule base NoSQL, un secteur trop de niche, mais bien une base moderne et générique, comme l’indique la communication de la société.
A partir de la version 4.0, dont la sortie est prévue à l’été 2018, MongoDB supportera ainsi les transactions multi-documents, avec toutes les garanties ACID que cela comporte. En gros, si jusqu’alors le modèle de documents permettait de garantir l’atomicité et une cohérence des données au sein d’un unique document, à partir de la prochaine version, les transactions qui impliquent des écritures sur plusieurs documents seront également ACID. Une approche qui permet à MongoDB de se hisser au même niveau que les bases relationnelles et d’en étendre les usages vers les systèmes les plus critiques. « La prise en charge des transactions ACID élimine toute hésitation des développeurs lorsqu’ils doivent choisir une base de données. Ils n'ont plus besoin de sacrifier la rapidité de développement et de céder à la crainte d’avoir besoin (à terme) de transactions dans une application », explique ainsi Eliot Horowitz, le CTO et co-fondateur de MongoDB, cité dans un communiqué.
Ce n’est toutefois pas une première que l’étiquette ACID est associée à une base NoSQL. MarkLogic, qui se présente aujourd’hui comme un hub de données opérationnelles, supporte historiquement les garanties ACID. A l’inverse de MongoDB (Open Source), MarkLogic repose sur un modèle propriétaire.
Des développements en cours de la v 3.0
Ce support des transactions multi-documents est le fruit de travaux qui durent depuis 3 ans, résume MongoDB. Cette capacité s’est d’ailleurs construite au fur et à mesure de développements effectuées sur toutes les couches de la base. Le fait de disposer d’un modèle de données non relationnel et de s’adosser à une architecture distribuée constitue en effet les deux principaux freins à la conformité ACID.
Des travaux ont ainsi été effectués sur le moteur de stockage, explique ainsi Grigori Melnik, patron des activités Product, Server & Tools de MongoDB, dans un billet de blog. WiredTiger, moteur par défaut de MongoDB, racheté par la société en 2014, a été révisé pour apporter la concurrence multi-versions, explique MongoDB dans une vidéo. D’autres développements ont été réalisés autour de l’ajout d’une horloge logique et d’un module baptisé Timestamp qui permettent de non seulement garantir un ordre dans les transactions passées, mais également d’identifier d’éventuelles relations entre ces transactions (et encore une fois d’instaurer un ordre) – une clé de la cohérence dans un modèle distribué.
Grigori Melnik liste également des travaux autour d’un protocole pour gérer le consensus et garantir la durabilité des données (le D d’ACID) et autour des réplicas de données pour la cohérence des données.
Si cette annonce modifie le positionnement de l’un des acteurs clé des bases de données, MongoDB ne semble pas attendre beaucoup d’activation de la fonction. « En raison de la différence fondamentale dans la modélisation des données (Document, donc, NDLR), les garanties d'atomicité existantes de MongoDB sont en mesure de répondre aux besoins d'intégrité des données dans la plupart des applications. En fait, nous estimons que 80 à 90% des applications n'ont pas besoin de transactions multi-documents », commente Grigori Melnik dans ce même billet de blog. Ajoutant qu’il existe toutefois « certains cas d'utilisation et workloads où des transactions entre plusieurs documents sont nécessaires » : ceux qui sont habitués au modèle relationnel et ne considère pas une base de données sans support des transactions ou encore d’autres qui n’en ont certes pas besoin aujourd’hui, mais pense que cela sera nécessaire dans le futur.
