Dans la première partie, nous avons introduit NuoDB et couvert ses principales fonctionnalités : Architecture 3-tiers, les noeuds sont des pairs identiques, l'Atom, unité de données fondamentales, et le système de gestion des versions et de la concurrence utilisé pour gérer les conflits et pour implémenter la cohérence des données.
Transactions à la volée
Maintenant que je vous ai expliqué le modèle global, la structure interne et le versionning, passons en revue quelques exemples simples qui nous aiderons à illustrer le fonctionnement de la base d'un point de vue pratique. Pour que l'exemple reste simple, considérons une simple base de données constituée de deux TEs et d'un SM. A partir de là, l'extrapolation vers une configuration plus complexe devrait s'avérer relativement simple.
Tout d'abord, observons la manière dont les Atoms sont remontés dans les caches des deux TEs. Supposons qu'un Atom soit archivé mais qu'il ne soit présent dans aucun des caches. Lorsque le client se connecte au premier TE et commence une transaction qui nécessite cet Atom, le TE va utiliser la structure de son catalogue pour découvrir qu'il n'existe pas de copie de cet Atom en cache et va donc s'adresser au SM pour charger cet objet. A partir de là, la structure du catalogue indique que l'Atom est dans le cache du premier TE, et ce TE assure l'arbitrage (Chairman) pour l'ensemble des données associées à celui-ci.
Quand une transaction démarre sur le second TE et qu'elle a besoin de données portées par le même Atom, le catalogue indique que cet Atom est disponible, aussi bien sur le SM que sur le premier TE. A présent, le second TE est libre de choisir où il veut charger l'Atom. En pratique, il va le charger à partir du premier TE parce que le chargement d'une copie en mémoire sera plus rapide. A ce stade, le catalogue est à jour pour indiquer que l'Atom est présent dans les deux caches.
A présent, observons ce qui se passe lorsque les données associées à cet Atom sont modifiées. En l'occurrence, disons que la mise à jour est effectuée sur une ligne contenue dans les données de l'Atom. Pour effectuer la modification, le TE qui exécute cette transaction a besoin d'envoyer deux messages : un message de mise à jour "en attente" à tous les pairs qui disposent d'une copie des données (dans notre cas, l'autre TE et le SM) ainsi qu'une requête au Chairman lui demandant l'autorisation d'effectuer cette modification. Si la mise à jour a lieu sur le premier TE, le second message est court-circuité parce que le TE local est le Chairman. Les messages sont asynchrones afin de ne pas bloquer la transaction. Si il n'y a pas de conflits, le Chairman va finalement répondre que la mise à jour est autorisée.
Dans le cas où deux transactions sont en train de mettre à jour les même données, il y a un conflit. La transaction qui arrive jusqu'au Chairman en premier "gagne". L'autre transaction recevra, au bout d'un moment, une réponse lui indiquant que la mise à jour a été refusée. La transaction "perdante" devra alors être annulée et retentée.
Plus tôt, j'ai mentionné que NuoDB supportait un protocole de commit flexible. Voilà où il rentre en jeu. Pour prévenir un client que la transaction a réussi, un TE doit toujours s'assurer du A,C et I de ACID. Ce sur quoi il dispose de flexibilité, c'est sur la Durabilité.
Dans l'exemple ci-dessus, les messages de mise à jour étaient envoyés de manière asynchrone à tous les pairs qui disposaient d'une copie de l'objet, ce qui incluait le SM. Bien que le message soit envoyé à travers un canal fiable, il n'y a aucun moyen de s'assurer que le SM a survécu suffisamment longtemps pour archiver durablement les données, à moins d'attendre un acquittement. Lors de la configuration de la base de données, il est possible de choisir si oui ou non le TE doit attendre cet acquittement avant de déclarer l'écriture réussie. Parce que vous pouvez optionnellement activer la journalisation, il y a plusieurs formes d'acquittements que vous pouvez attendre d'un SM.
Ainsi, un commit pourrait vouloir dire que les messages ont été envoyés à tous les noeuds, ou que le SM a répondu que le changement a été journalisé ou archivé durablement. Un commit peut aussi vouloir dire qu'au moins un nombre minimal de SMs ont répondu. Ce qui vous offre la flexibilité de choisir l'importance que vous accordez à la garantie de durabilité face à la rapidité de votre base de données distribuée.
La couche d'administration
J'ai indiqué plus tôt que NuoDB disposait d'une couche d'administration. Cette couche est responsable de la scalabilité horizontale à la demande et des modèles de migration que nous vous avons présenté plus haut. Chaque hôte du système dispose d'un agent local de gestion, et l'ensemble des agents forment un réseau pair-à-pair qui est séparé de la base de données en elle-même. Nous appelons cet ensemble d'hôtes inter-connectés un Domain.
La vue de management simple et logique offerte par un Domain le rend simple à monitorer, à administrer et permet d'automatiser les tâches d'administration. Chaque agent est responsable de son hôte local, et certains seront exécutés en tant que Broker, ce qui leur donne un accès au Domain dans son ensemble. Les Brokers sont identiques du point de vue de leur connaissance et de leurs responsabilités, donc, tant que vous disposez d'au moins un Broker disponible, vous avez toujours accès aux interfaces d'administration et d'automatisation. A l'aide des Brokers, vous pouvez démarrer, arrêter ou migrer des bases de données, modifier votre configuration, monitorer et capturer des logs des TEs et des SMs et vous assurer que tout fonctionne correctement.
Parce qu'une base de données est simplement un ensemble de processus en cours d'exécution, il est simple d'exécuter plusieurs bases de données sur un même hôte. En d'autres termes, la couche d'administration supporte des déploiement multi-tenants où chaque tenant est en fait en train d'utiliser sa propre base de données qui est isolée d'un point de vue processus, protégée à l'aide de canaux sécurisé dédiés et qui stocke les données dans ses archives propres. Combien de bases de données peut on installer sur un même système? Nous avons tout écrit sur le sujet sur notre blog sur l'habilité à supporter des déploiements denses.
Les Broker sont utilisés par les clients SQL pour trouver les TEs quand ils se connectent à la base de données. Les Broker agissent comme de simples répartiteurs de charge qui sont conscients de ce qui se passe sur le Domain et qui peuvent prendre des décisions intelligentes sur la répartition des connexions des clients.
Réunir tous les éléments
En tenant compte de toutes ces fonctionnalités et en revenant sur mes commentaires d'origine sur ce que signifiait le fait d'être cloud-scale, je pense qu'il existe quelques cas d'utilisation pour lesquels NuoDB est la seule solution adaptée. Tout d'abord, le système supporte une scalabilité horizontale automatisée à la demande. Cette habilité lui permet d'offrir de la haute disponibilité. Pas de haute disponibilité par provisionnement de pièces de rechange, mais de la haute disponibilité capable de détecter les pannes du système et de rapidement connecter de nouvelles ressources. Cette haute disponibilité réactive signifie que vous n'avez pas besoin de sur-dimensionner votre système pour vous prémunir des pannes, tout en conservant une bonne tolérance à la panne.
D'autre part, NuoDB permet de fournir une vision simple et logique pour les base de données déployées dans plusieurs data centers ou distribuées à travers plusieurs régions géographiques. Évidement, ceci nous aide pour la haute disponibilité mais il s'agit aussi d'un point critique pour toute application où les utilisateurs sont physiquement séparés et où vous voulez les rapprocher de leurs applications et de leurs données. NuoDB supporte bien la distribution géographique parce que la répartition des données tend à être faite en fonction des clients qui y accèdent. Donc, entre de la simple répartition de charge, du cache à la demande et de la réplication asynchrone entre les régions, une base donnée conserve la plupart de ses messages de coordination en local, pour une région donnée.
Troisièmement, parce que MVCC offre à NuoDB un mode d'isolation des snapshots efficace, le système est très efficace pour supporter une montée en charge opérationnelle et analytique sur un même ensemble de données. En d'autres termes, de longues requêtes, en lecture seule, qui s'exécutent sans conflits sur des données fréquemment mises à jour. Ceci aide à simplifier les développements qui s'appuieraient autrement sur plusieurs bases en tentant de synchroniser le jeu de données.
Enfin, NuoDB est conçue pour permettre une bonne automatisation. Que ce soit sur la scalabilité horizontale à la demande ou du point de vue de l'efficacité du multi-tenant, nous gérons les bases de données en tant que services qui devraient être gérés par des SLAs ou des règles simples. C'est ce choix qui guide le développement de NuoDB.
La suite pour NuoDB?
Ce que j'ai essayé d'illustrer dans cet article c'est que NuoDB représente une nouvelle architecture, conçue dès le départ pour la scalabilité horizontale, le déploiement agile et l'automatisation. Il est simple de provisionner de nouveaux hôtes pour étendre sa capacité, d'automatiser son expansion quand il y a des pics de charge ou des pannes et de répartir les bases de données à travers plusieurs data centers. Pour revenir à ce qui a démarré cet article, je pense que nous pouvons qualifier NuodDB de base de données cloud-scale.
Ce sur quoi nous travaillons actuellement, c'est la facilité d'automatisation du système. A l'aide de SLAs simples, vous serez capables de définir exactement ce dont vous avez besoin en matière de base de données. Que vous soyez en train de développer sur votre laptop, de gérer les bases de données internes à votre société ou de mettre en place une offre de services sur Internet, NuoDB se présentera comme un simple service.
Parallèlement, nous sommes en train d'étendre les fonctionnalités offertes par une base de données distribuée selon un critère géographique. Ce qui vous offrira de la flexibilité face aux panes et de meilleures garanties sur la disponibilité des données. Nous sommes aussi en train d'étoffer le modèle de programmation côté serveur, la parallélisation au niveau de la couche de stockage et nos APIs aussi bien pour le SQL que pour les clients d'administration. J'espère que vous essaierez la base de données, et faites moi savoir ce que vous en pensez.
A propos de l'auteur
.jpg)
Seth Proctor est le CTO de NuoDB, Inc. il a 15 ans d'expérience dans la recherche, la conception et l'implémentation de système scalables. Cette expérience inclue des travaux sur les réseaux, les langages, les systèmes d'exploitation, la sécurité, les bases de données et les environnements distribués, qui font partie partie intégrante du projet NuoDB. Avant d'intégrer NuoDB, Seth travaillait pour Nokia sur l'architecture de leur cloud interne privé. Avant cela, il était chez Sun Microsystem où il travaillait dans les laboratoires de recherches et il collaborait avec des groupes produits et des universités.
Seth détient huit brevets suite à son travail dans plusieurs disciplines techniques. Il dispose de cinq autres brevets en cours d'approbation, liés aux performances des bases de données et à l'agilité de l'utilisateur final dans les déploiements de la base de données centralisée NuoDB. Vous pouvez le contacter ici