Architecture Lakebase
Bêta
Depuis le 15 juin, Lakebase est disponible en version bêta sur GCP. Voir Region availability pour les régions prises en charge.
Lakebase sépare le stockage du compute. Le moteur Postgres qui exécute vos query est sans état, et vos données résident dans une couche de stockage durable qui persiste indépendamment. Cette séparation est ce qui rend possibles la mise à l'échelle automatique, la mise à l'échelle jusqu'à zéro, les Branch instantanées, les réplicas de lecture et le basculement rapide.
Pour montrer ce que Lakebase change, cette page commence par présenter la conception traditionnelle de base de données sur machine unique à des fins de comparaison, puis explique comment Lakebase sépare cette même conception en couches indépendantes et le rôle de chaque élément.
Comment une base de données traditionnelle est construite
Avant de regarder Lakebase, considérez le modèle qu’il remplace. Une base de données Postgres conventionnelle est un monolithe. Une seule machine exécute le moteur de requête et écrit à la fois le journal d’écriture anticipée (WAL) et les fichiers de données sur un disque connecté à un point de montage local. Traditionnellement, ces disques étaient véritablement locaux, faisant partie d’une même machine, mais à mesure que l’infrastructure a évolué, ils sont souvent devenus des dispositifs de stockage connectés en réseau.
Le WAL et les fichiers de données jouent deux rôles complémentaires :
- Le WAL accélère les écritures. Postgres ajoute chaque modification au log de manière séquentielle avant d'accuser réception d'un commit, ce qui est rapide et durable sur un disque unique.
- Les fichiers de données accélèrent les lectures. Postgres matérialise la version actuelle de chaque page dans des fichiers de données, de sorte qu’une query peut lire une ligne sans rejouer le log.
L'accès à l'ensemble de vos données via une seule machine présente des inconvénients :
- La durabilité est directement liée à l'infrastructure physique de cette machine. Vous devez également pré-provisionnement le stockage et prédire la croissance de votre charge de travail, ce qui complique à la fois la gestion des coûts et la planification de la résilience.
- La haute disponibilité et de nombreux types de mise à l'échelle horizontale nécessitent des clones physiques de l'intégralité de la base de données.
- En cas de défaillance de cette machine, vous risquez de perdre des données. Des techniques comme le stockage RAID réduisent ce risque, mais la redondance ajoutée peut augmenter considérablement le coût d'exploitation du système.
L’architecture Lakebase
Lakebase conserve les mêmes responsabilités mais les sépare en deux couches indépendantes :
- Une couche de compute qui exécute Postgres standard et sans état.
- Une couche de stockage composée de safekeepers, de pageservers et de stockage d'objets cloud.
Les deux rôles du monolithe correspondent directement aux nouveaux composants. Le WAL, qui accélérait les écritures, devient les safekeepers , qui permettent de monter en charge les écritures. Les fichiers de données, qui accéléraient les lectures, deviennent les pageservers , qui permettent de monter en charge les lectures.
Comme les données résident dans un stockage d’objets cloud plutôt que sur une seule machine, Lakebase fournit un compute élastique et évolutif ainsi que des écritures durables répliquées entre les zones de disponibilité. Il n’y a aucun stockage à provisionner : vous ne payez que pour le stockage que vous consommez, et vous n’avez pas à prévoir de modes de défaillance tels que le manque d’espace disque.
Ce modèle améliore également les performances. Lakebase écrit chaque modification directement vers plusieurs emplacements, évitant ainsi la surcharge liée à la protection traditionnelle contre les écritures fragmentées (torn-write) et à l'alignement des blocs. Comme chaque écriture est déjà effectuée vers plusieurs emplacements, les performances restent constantes, que la haute disponibilité soit activée ou non.
Le tableau suivant fait correspondre chaque partie du monolithe à son équivalent Lakebase.
Monolithe traditionnel | Lakebase | Rôle |
|---|---|---|
Machine unique | Compute sans état | Exécute le moteur de query Postgres |
Disque WAL local | Safekeepers | Enregistre durablement chaque modification validée |
Fichiers de données locaux | Pageservers et stockage d'objets | Matérialise et stocke les versions de page |
Couche Compute
La couche de compute exécute Postgres. Il ne contient que des états transitoires : les tampons partagés Postgres en mémoire et un cache de compute local pris en charge par un disque local rapide. Il ne possède aucune donnée durable.
Parce que compute ne possède pas d’état durable :
- Il peut être remplacé, redémarré, mis à l'échelle automatiquement ou dimensionné à zéro sans déplacer ni perdre de données.
- Au lieu d'écrire sur un système de fichiers local, il Stream le WAL vers la couche de stockage.
- Plusieurs instances de compute peuvent se connecter à la même couche de stockage, ce qui permet le fonctionnement des réplicas de lecture et du basculement rapide de Lakebase.
Couche de stockage
La couche de stockage est durable et fonctionne indépendamment du compute. Il comporte trois composants.
Safekeepers
Les safekeepers sont le WAL, extrait de la machine unique et rendu hautement disponible. À mesure que Postgres produit des enregistrements WAL, il les Stream vers un groupe de safekeepers qui répliquent le log au sein d'un quorum en utilisant un protocole de consensus basé sur Paxos.
Une transaction est validée lorsqu’un quorum de safekeepers accuse réception de l’enregistrement WAL, et non lorsqu’une seule machine termine un fsync commit. La durabilité provient de la réplication sur plusieurs nœuds plutôt que d’un seul disque.
Pageservers
Les pageservers sont les fichiers de données, extraits et reconstruits à partir du WAL. Un pageserver consomme le Stream WAL provenant des safekeepers et matérialise les versions de page à la demande. Lorsque le compute demande une page à un numéro de séquence de log (LSN) spécifique, le pageserver la reconstruit et la renvoie.
Les pageservers agissent comme un cache à écriture traversante au-dessus du stockage d'objets. Ils persistent de manière asynchrone les pages matérialisées vers le stockage d'objets cloud, et la reconstruction des pages ne bloque pas le commit d'une transaction.
Stockage d'objets cloud
Le stockage d'objets cloud constitue la base de durabilité de l'ensemble de la couche de stockage. Il contient les données de page que les serveurs de pages conservent.
Sur GCP, Lakebase conserve les données dans Google Cloud Storage.
Le stockage d'objets reste en dehors du chemin de query à chaud. Seuls les pageservers y lisent des données. Pour plus de détails sur le fonctionnement de la redondance du stockage et sur les raisons pour lesquelles elle est indépendante du paramètre de haute disponibilité du compute, consultez Architecture de stockage.
Fonctionnement d’une écriture
Une écriture circule du compute à travers la couche de stockage :
- Postgres modifie les pages concernées en mémoire et produit des enregistrements WAL.
- Le compute Stream les enregistrements WAL vers les safekeepers.
- Lorsqu'un quorum de safekeepers accuse réception des enregistrements, la transaction est validée (commit) et le client reçoit une confirmation de succès.
- Les Pageservers appliquent le WAL de manière asynchrone et conservent les pages mises à jour dans le stockage d'objets.
Une transaction est durable dès qu'un quorum de safekeepers possède l'enregistrement WAL, car le log suffit à lui seul pour reconstruire les données. Les pageservers reconstruisent et stockent les pages de données par la suite, en dehors du chemin de commit, afin que les écritures restent rapides sans mettre en péril aucune modification validée.
Comment fonctionne une lecture
Les lectures vérifient une hiérarchie de caches, du plus rapide au plus lent, et s'arrêtent à la première couche qui contient la page :
- Pool de tampons (mémoire) : les tampons partagés Postgres dans la RAM du compute.
- Cache local de compute : un cache sur disque situé sur le nœud de calcul, dimensionné en fonction de la mémoire du compute.
- Pageserver : en cas d'échec du cache, le compute demande la page à un pageserver, qui la reconstruit au LSN demandé.
- Stockage d'objets : le pageserver lit en interne à partir du stockage d'objets lorsque cela est nécessaire. Les queries n'atteignent pas directement le stockage d'objets.
Ce que cette architecture permet
La séparation du compute sans état et du stockage durable est ce qui rend possibles plusieurs fonctionnalités de Lakebase :
Fonctionnalité | Ce que cela permet |
|---|---|
Comme le compute est sans état, Lakebase augmente ou diminue la taille du compute en réponse à la charge de travail sans déplacer les données. | |
Le compute peut être mis en pause complète tandis que le stockage persiste, et les données sont immédiatement disponibles lorsque le compute reprend. | |
Créez une copie isolée et inscriptible de votre base de données en quelques secondes. Comme le branching est une opération de métadonnées de type copy-on-write sur un stockage partagé, il ne duplique aucune donnée. | |
Plusieurs instances de compute lisent à partir de la même couche de stockage, de sorte que les réplicas n'ont pas besoin de copies de données et start en quelques secondes. | |
Comme la couche de stockage conserve l'historique, le compute peut s'attacher à un point temporel passé et lire la base de données telle qu'elle existait à ce moment-là, sans avoir à copier les données. | |
Le basculement promeut une instance de compute secondaire qui se connecte au stockage existant, sans transfert de données. | |
RPO = 0 (aucune perte de données validées) | Lakebase enregistre durablement chaque transaction engagée avant de la reconnaître, donc vous ne perdez aucune donnée engagée lorsque le compute échoue, redémarre ou monte en charge à zéro. |
Comment cette architecture prend en charge le LTAP
Comme Lakebase stocke durablement chaque modification validée dans le stockage d'objets cloud, les mêmes données peuvent servir aux workloads analytiques et aux transactions sans pipeline de réplication distinct. C'est la base du traitement transactionnel et analytique de lac (LTAP), où une copie unique de vos données prend en charge à la fois les moteurs transactionnels et analytiques. Pour savoir comment le LTAP s'appuie sur cette architecture, consultez l'architecture LTAP.
Étapes suivantes
- Architecture de stockage : découvrez comment fonctionne la redondance du stockage et pourquoi elle est indépendante du paramètre de haute disponibilité du compute. Voir Architecture de stockage.
- Branches de base de données : découvrez comment les branches utilisent le stockage copy-on-write pour créer des environnements isolés instantanés. See Branch.
- Réplicas en lecture : ajoutez des instances de compute en lecture seule qui partagent la même couche de stockage. Voir Réplicas en lecture.
- Concepts fondamentaux : passez en revue l’ensemble des concepts qui rendent Lakebase unique. Voir Concepts fondamentaux.