Imaginez que vous essayez d'organiser une bibliothèque massive et chaotique où des millions de personnes tentent d'emprunter, de lire et de réécrire des livres exactement au même moment. Dans le monde de l'informatique, c'est le défi des bases de données : des systèmes qui stockent des informations afin que les applications puissent les trouver et les modifier instantanément. Pendant des décennies, la grande question était de savoir comment faire croître ces bibliothèques pour qu'elles puissent gérer l'ensemble d'Internet sans s'effondrer. L'ancienne méthode consistait en un seul bibliothécaire qui devait tamponner chaque livre, créant une longue file d'attente qui ralentissait tout le monde. La méthode plus récente, de la « cohérence éventuelle », consistait à laisser les gens deviner ce que disait le livre et à corriger les erreurs plus tard, ce qui est rapide mais risqué si vous avez besoin de la vérité à l'instant présent. L'objectif de l'ingénierie moderne des bases de données est de construire un système aussi rapide que la méthode du tâtonnement, mais aussi fiable que la méthode du tampon, capable de gérer des millions de transactions par seconde sans que personne n'ait jamais à gérer les étagères manuellement.

Ce document présente Aurora DSQL, un nouveau type de base de données conçu par Amazon Web Services pour résoudre exactement ce problème. Considérez cela comme une bibliothèque super intelligente et autonome qui peut s'étendre ou se réduire instantanément en fonction du nombre de visiteurs. Les auteurs ont construit un système qui sépare la « réflexion » (l'exécution du code SQL) du « stockage » (la conservation des livres) et des « règles » (s'assurer que deux personnes ne modifient pas la même page en même temps). En utilisant un « Journal » spécial qui agit comme un journal intime permanent et immuable de chaque modification effectuée, DSQL permet aux différentes parties du système de travailler indépendamment. Le document montre que cette conception permet à la base de données de passer de zéro utilisateur à des millions de transactions par seconde, de fonctionner sur différents continents sans ralentir, et de maintenir les données parfaitement cohérentes afin que vous n'ayez jamais à vous soucier de lire un livre que quelqu'un d'autre est en train de réécrire.

La magie de la bibliothèque déconnectée

Pour comprendre comment fonctionne Aurora DSQL, imaginez une immense bibliothèque où les bibliothécaires, les étagères et les gardiens des règles sont tous dans des bâtiments différents, reliés par des télégrammes ultra-rapides. Dans les anciens systèmes, ces parties étaient soudées ; si les étagères devenaient trop pleines, toute la bibliothèque devait s'arrêter et se réorganiser. DSQL les sépare.

D'abord, il y a les Processeurs de Requêtes (Query Processors). Ce sont les bibliothécaires qui communiquent avec vous. Lorsque vous demandez un livre, ils ne transportent pas les livres lourds eux-mêmes. Au lieu de cela, ils fonctionnent à l'intérieur de petites pièces virtuelles sécurisées appelées Firecracker MicroVMs. Ces pièces sont si efficaces qu'elles peuvent être créées ou détruites en un clin d'œil. Si vous avez un afflux soudain de visiteurs, le système construit instantanément plus de pièces. Si l'afflux s'arrête, il les détruit pour que vous ne payiez pas pour de l'espace vide. C'est la partie « serverless » : vous ne gérez pas les bibliothécaires ; ils apparaissent simplement quand vous en avez besoin.

Ensuite, il y a les Nœuds de Stockage (Storage Nodes). Ce sont les étagères. Ils ne détiennent pas toute la bibliothèque ; ils ne détiennent que des sections spécifiques de livres basées sur une « clé de partitionnement » (comme le tri des livres par la première lettre du nom de l'auteur). Parce que les bibliothécaires et les étagères sont séparés, les bibliothécaires peuvent mener leur propre activité sans attendre que les étagères les rattrapent. Ils lisent à partir de l'étagère la plus proche dans leur propre quartier (Zone de Disponibilité), ce qui rend la lecture incroyablement rapide.

Enfin, il y a les Adjudicateurs (Adjudicators) et le Journal. Les Adjudicateurs sont les gardiens des règles qui décident si un changement est autorisé. Le Journal est le journal de bord maître. Lorsque vous voulez modifier un livre (une « écriture »), le bibliothécaire écrit le changement sur un morceau de papier mais ne le met pas encore sur l'étagère. Il l'envoie au gardien des règles. Le gardien vérifie si quelqu'un d'autre essaie de modifier ce même livre en même temps. Si c'est libre, le gardien inscrit le changement dans le Journal. Ce Journal est la partie la plus importante : c'est une liste ordonnée et permanente de chaque changement qui s'est jamais produit. Une fois qu'une chose est dans le Journal, elle est en sécurité pour toujours, même si les étagères ou les bibliothécaires disparaissent.

L'astuce de lecture « sans attente »

L'un des trucs les plus cool de ce document est la façon dont il gère la lecture. Dans de nombreuses bases de données, si vous voulez lire un livre, vous devez attendre que le bibliothécaire s'assure que personne n'est en train d'écrire dedans. Cela crée des files d'attente et des délais. DSQL utilise une astuce de voyage dans le temps très ingénieuse appelée Contrôle de Concurrence Multi-Versions (MVCC - Multi-Version Concurrency Control).

Imaginez que chaque fois qu'un livre est modifié, la bibliothèque ne supprime pas l'ancienne version. Au lieu de cela, elle crée une nouvelle copie avec un horodatage. Lorsque vous demandez un livre, vous ne demandez pas « le livre » ; vous demandez « le livre tel qu'il était à 14h00 ». Le système trouve alors la version qui était valide à 14h00. Comme le système utilise des horloges ultra-précises (exactes à la microseconde), il sait exactement quelle version vous montrer. Cela signifie que vous pouvez lire un livre pendant que quelqu'un d'autre en écrit un nouveau, et vous ne verrez pas ses modifications désordonnées et inachevées. Vous voyez un instantané parfait et figé du passé. Cela permet à des millions de personnes de lire simultanément sans jamais se bloquer les unes les autres.

Le super-pouvoir multi-régions

Le document traite également du problème de la distance. Habituellement, si vous avez une bibliothèque à New York et une autre à Londres, les maintenir synchronisées prend du temps à cause de la vitesse de la lumière. Si vous essayez de mettre à jour un livre aux deux endroits en même temps, vous devez attendre qu'un message traverse l'océan, ce qui ralentit tout.

DSQL résout cela en étant actif-actif. Cela signifie que vous pouvez avoir une bibliothèque à New York et une bibliothèque à Londres, et les deux sont pleinement ouvertes aux affaires en même temps. Lorsque vous effectuez un changement à New York, le système l'écrit dans le Journal. Le Journal envoie ensuite une copie à Londres. La magie est que cela ne se produit qu'une seule fois, au moment précis où vous cliquez sur « commit » (terminer la transaction). Le système ne vous empêche pas de lire ou d'écrire pendant que le message voyage. Il utilise un système de « quorum », ce qui signifie qu'il a seulement besoin de confirmer le changement dans deux régions sur trois pour le déclarer sûr.

Les auteurs ont mesuré cela et ont constaté que même avec la distance entre la Virginie et l'Oregon (environ 62 millisecondes aller-retour), le système ne paie cette « taxe de distance » qu'une seule fois par transaction. Pour la lecture, c'est encore plus rapide car vous lisez depuis la bibliothèque locale. Les auteurs montrent que cette conception permet à la base de données de rester rapide et cohérente même si une région entière (comme une ville entière) devient hors ligne en raison d'une catastrophe.

Les règles du jeu

Les auteurs ont été très prudents quant à ce qu'ils promettaient. Ils ont choisi l'Isolation par Instantané (Snapshot Isolation), qui est un ensemble spécifique de règles sur la façon dont les transactions se comportent. C'est comme dire : « Vous pouvez lire le livre tel qu'il était lorsque vous avez commencé à lire, et vous pouvez le modifier quand vous avez fini, mais si quelqu'un d'autre l'a modifié entre-temps, vous devez réessayer. » Cela diffère des règles plus strictes qui vous forceraient à attendre un verrou, ce qui ralentit les choses.

Le document exclut explicitement l'idée que vous avez besoin d'un « leader » unique pour tout gérer. Dans de nombreux systèmes, un ordinateur est le chef, et s'il tombe en panne, tout s'arrête. DSQL n'a pas de chef unique. Chaque partie peut augmenter ou diminuer sa capacité, et si une partie échoue, les autres continuent simplement de fonctionner. Le document exclut également l'idée que vous devez gérer le matériel vous-même. Le système gère la « chaleur » (les parties qui deviennent trop occupées) automatiquement. Si une section de la bibliothèque devient trop encombrée, le plan de contrôle (le gestionnaire de la bibliothèque) divise automatiquement cette section en deux parties plus petites et déplace certains livres vers une nouvelle étagère, le tout sans que vous n'ayez rien à faire.

Tester la théorie

Les auteurs n'ont pas seulement supposé que cela fonctionnerait ; ils l'ont testé intensément. Ils ont utilisé une méthode appelée simulation déterministe, où ils ont fait fonctionner le système dans un programme informatique capable de simuler des millions d'erreurs, de retards réseau et de pannes en une fraction de seconde. Ils ont découvert que le système pouvait gérer ces erreurs sans perdre de données ou s'embrouiller.

Ils ont également effectué des tests de type réel (comme le benchmark TPC-C, qui simule un magasin très fréquenté). Les résultats ont montré que DSQL pouvait passer d'un démarrage à froid (où il possède très peu de ressources) à la gestion de millions d'opérations par minute. Il lui a fallu environ 25 minutes pour atteindre sa pleine vitesse à partir d'un état complètement vide, mais une fois « chaud », il était incroyablement rapide. Le document note que bien qu'ils soient très confiants dans ces résultats, ils travaillent encore sur l'ajout de fonctionnalités supplémentaires comme les clés étrangères (qui lient les tables entre elles) et les procédures stockées.

L'essentiel

Aurora DSQL est la preuve que l'on peut avoir le meilleur des deux mondes : une base de données aussi facile à utiliser qu'un service simple (où vous ne gérez rien) et aussi puissante qu'un système mondial massif. En séparant la réflexion, le stockage et les règles, et en utilisant un journal permanent pour suivre le temps, elle permet aux applications de passer de zéro à des millions de transactions sans sourciller. C'est un système conçu pour un monde où les choses changent vite, où les catastrophes arrivent, et où vous avez besoin de savoir que l'information que vous lisez est la vérité absolue, là, maintenant.