Avec NuoDB, la base de données SQL devient distribuée

Une architecture totalement distribuée 

L’architecture de la base de données NeoDB s’appuie sur trois composants principaux. Le premier d’entre eux est un broker qui se charge d’interpréter les requêtes JDBC, ODBC et SQL provenant des différents clients. Ce broker agit comme un interpréteur mais aussi comme un répartiteur de charge pour les requêtes. Le second composant est un moteur transactionnel qui se charge d’assurer le caractère ACID (Atomicité, Consistance, Isolation et durabilité) des transactions, bref qui garantit que NuoDB se comporte comme une vraie base de données relationnelles pour ce qui est de la consistance des transactions. Enfin, le dernier composant est un moteur de stockage qui s’appuie sur un système de type clé/valeur (Key Value Store). Ce moteur peut s’appuyer sur un stockage local mais aussi sur des services de stockages tels que S3 d’Amazon ou HDFS (Hadoop File System), pour peu que ces stockages répondent aux contraintes de performances requises.

Comme l’explique Morris, chacun de ces composants peut être dupliqué à volonté en fonction des besoins de montée en charge de la base de données (et il n'y a aucune notion de maître ou d'esclave). Il est ainsi possible de multiplier les moteurs de stockage afin de garantir une intégrité optimale pour les données (les données sont répliquées entre Key Value Stores) ou de déployer un grand nombre de moteurs transactionnels pour faire face à un grand nombre de transactions. L’architecture a, selon Morris, l’avantage de monter en charge de façon quasi linéaire avec l’accroissement du nombre de nœuds mais elle permet aussi de concevoir des bases de données à une échelle mondiale en dispersant géographiquement les différents composants (dans ce cas les composants locaux seront toujours privilégiés pour des raisons évidentes de latence). L’ensemble des composants ainsi distribués entre les différentes géographies fonctionnent en mode actif/actif. Il est à noter que les différents éléments ont leur intelligence propre et sont conçus pour optimiser leurs interactions avec les autres éléments. Ainsi un moteur transactionnel confronté à un moteur de stockage saturé, privilégiera automatiquement un autre moteur de stockage moins saturé afin d’assurer une répartition de la charge. 

De fait, NuoDB semble avoir créé ce qui est une base de données distribuée à même de stocker ses données de façon « atomique » et de les répliquer d’une géographie à une autre tout en assurant le caractère ACID des transactions. 

NuoDB vise le marché des SGBDR traditionnelles ainsi que le marché web

L’architecture de NuoDB se pilote au travers d’une interface web centralisée qui permet de déployer à la volée de nouvelles instances des différents composants de la base de données et qui permet aussi de déployer de nouveaux schémas de base de données en quelques clics. L’interface est conçue pour être accessible par de multiples locataires qui ne voient que la partie que l’administrateur leur laisse accéder (en ce sens, la base est conçue dès le départ pour être multitenant). NuoDB est conçu pour supporter des centaines de milliers d’utilisateurs et des dizaines de milliers de transactions simultanées.

La version finale de la base NuoDB est attendue dans le courant du mois de décembre. Elle vise le marché des bases de données traditionnelles (Oracle, SQL Server, DB2) ainsi que celui des bases de données à grande échelle pour les fournisseurs de services et grands acteurs du web. Dans ce dernier cas, l’un de ses grands atouts est d’éviter le phénomène de « sharding » qui se traduit par un découpage en tranche des bases de données et par la création d’architectures en « pod ».