Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lakebase sépare le stockage du calcul. Le moteur Postgres qui gère vos requêtes 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 possible l’autoscaling, le scale-to-zéro, les branches instantanées, les répliques de lecture et le basculement rapide.
Pour montrer ce que Lakebase change, cette page commence par la conception traditionnelle de base de données monomachine pour le contraste, puis explique comment Lakebase sépare ce même design en couches indépendantes et ce que fait chaque pièce.
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 journal de manière séquentielle avant d’accuser réception d’un commit, ce qui est rapide et durable sur un seul disque.
- Les fichiers de données accélèrent les lectures. Postgres matérialise la version actuelle de chaque page sous forme de fichiers de données, afin qu’une requête puisse lire une ligne sans rejouer le journal.
Accéder à toutes vos données via une seule machine présente des inconvénients :
- La durabilité est directement liée à l’infrastructure physique de cette machine. Il faut aussi pré-provisionner le stockage et prévoir l’augmentation 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’ensemble de la base de données.
- Si cette machine tombe en panne, vous pouvez perdre des données. Des techniques comme le stockage RAID réduisent ce risque, mais la redondance supplémentaire peut considérablement augmenter le coût d’exploitation du système.
L’architecture de la base du lac
Lakebase conserve les mêmes responsabilités mais les divise en deux couches indépendantes :
- Une couche de calcul qui exécute des Postgres standards, sans état.
- Une couche de stockage composée de safekeepers, de serveurs de pages et de stockage d’objets dans le cloud.
Les deux rôles du monolithe sont directement transférés aux nouveaux composants. Le WAL, qui accélérait les écritures, devient le garde-fou, qui évolue en écriture. Les fichiers de données, qui accéléraient les lectures, deviennent les serveurs de pages, qui scalent les lectures.
Parce que les données résident dans un stockage d’objets cloud plutôt que sur une seule machine, Lakebase offre un calcul élastique, évolutif et des écritures durables répliquées entre les zones de disponibilité. Il n’y a pas de stockage à provisionner : vous ne payez que pour le stockage consommé, et vous n’avez pas à prévoir en fonction des modes de défaillance comme la rupture de disque.
Ce modèle améliore également les performances. Lakebase écrit chaque changement directement à plusieurs emplacements, évitant ainsi la surcharge de la protection traditionnelle contre l’écriture déchirée et de l’alignement des blocs. Comme chaque écriture est déjà envoyée à plusieurs endroits, la performance reste constante, que la haute disponibilité soit activée ou non.
Le tableau suivant correspond chaque partie du monolithe à son homologue de Lakebase.
| Monolithe traditionnel | Lakebase | Rôle |
|---|---|---|
| Une machine | Calcul sans état | Exécute le moteur de requête Postgres |
| Disque WAL local | Gardiens de sécurité | Enregistre durablement chaque changement engagé |
| Fichiers de données locaux | Serveurs de pages et stockage d’objets | Matérialise et stocke les versions des pages |
Couche de calcul
La couche de calcul exécute Postgres. Il ne conserve que l’état transitoire : le Postgres partageait des tampons en mémoire et un cache de calcul local soutenu par un disque local rapide. Il ne possède aucune donnée durable.
Parce que le calcul ne possède pas d’état durable :
- Elle peut être remplacée, redémarrée, auto-mise à l’échelle ou mise à l’échelle à zéro sans déplacer ni perdre de données.
- Au lieu d’écrire dans un système de fichiers local, il transmet le WAL vers la couche de stockage.
- Plusieurs instances de calcul peuvent se connecter à la même couche de stockage, ce qui est le fonctionnement de Lakebase pour lire les répliques et le basculement rapide .
Couche de stockage
La couche de stockage est durable et fonctionne indépendamment du calcul. Il comporte trois composantes.
Gardiens de sécurité
Les Safekeepers sont les WAL, extraits de la machine unique et rendus très accessibles. Au fur et à mesure que Postgres produit les enregistrements WAL, il les transmet à un groupe de gardiens de sécurité qui répliquent le journal à travers un quorum en utilisant un protocole de consensus basé sur Paxos.
Une transaction s’engage lorsqu’un quorum de gardiens de sécurité accuse réception de l’enregistrement WAL, et non lorsqu’une seule machine termine un fichier local fsync. La durabilité provient de la réplication entre les nœuds plutôt que d’un seul disque.
Serveurs de pages
Les serveurs de pages sont les fichiers de données, extraits et reconstruits depuis le WAL. Un serveur de pages consomme le flux WAL des safekeepers et matérialise les versions des pages à la demande. Lorsque le calcul demande une page à un numéro de séquence de journal (LSN) spécifique, le serveur de pages la reconstruit et la retourne.
Les serveurs de pages agissent comme un cache d’écriture au-dessus du stockage d’objets. Ils persistent de façon asynchrone les pages matérialisées vers le stockage d’objets dans le cloud, et la reconstruction de page ne bloque pas un commit de transaction.
Stockage d’objets cloud
Le stockage d’objets dans le cloud est la base de durabilité de toute la couche de stockage. Il contient les données de page que les serveurs de pages persistent.
Sur Azure, Lakebase persiste les données vers Stockage Blob Azure.
Le stockage objet reste hors du chemin de la requête à chaud. Seuls les serveurs de pages en lisent. Pour plus de détails sur le fonctionnement de la redondance de stockage et pourquoi elle est indépendante du paramètre de haute disponibilité de calcul, voir Architecture de stockage.
Comment fonctionne une écriture
Une écriture s’écoule du calcul à travers la couche de stockage :
- Postgres modifie les pages affectées en mémoire et produit des enregistrements WAL.
- Compute transmet les enregistrements WAL aux gardients de sécurité.
- Lorsqu’un quorum de gardiens de sécurité accuse réception des dossiers, la transaction s’engage et le client obtient le succès.
- Les serveurs de pages appliquent le WAL de manière asynchrone et persistent les pages mises à jour dans le stockage d’objets.
Une transaction est durable dès qu’un quorum des gardiens de sécurité possède l’enregistrement VAL, car le journal seul suffit à reconstituer les données. Les pages servers reconstruisent et stockent ensuite les pages de données, hors du chemin de validation, afin que les écritures restent rapides sans mettre en danger de changement engagé.
Comment fonctionne une lecture
Les lectures vérifient une hiérarchie de caches, du plus rapide au plus lent, et s’arrêtent au premier calque qui contient la page :
- Pool de tampon (mémoire) : Les Postgres partageaient des tampons dans la RAM de calcul.
- Cache de calcul local : Un cache soutenu par disque sur le nœud de calcul, dimensionné par rapport à la mémoire du calcul.
- Serveur de pages : En cas de rate de cache, le calcul demande la page à un serveur de pages, qui la reconstruit au LSN demandé.
- Stockage d’objets : Le serveur de pages lit depuis le stockage objet en interne lorsque cela est nécessaire. Les requêtes n’atteignent pas directement le stockage d’objets.
Ce que cette architecture permet
La séparation du calcul sans état du stockage durable est ce qui rend possibles plusieurs fonctionnalités de Lakebase :
| Fonction | Ce que cela permet |
|---|---|
| Mise à l’échelle automatique | Comme le calcul est sans état, Lakebase scale la taille de calcul vers le haut ou vers le bas en réponse à la charge de travail sans déplacer les données. |
| Mise à l’échelle à zéro | Le calcul peut être complètement mis en pause tant que le stockage persiste, et les données sont immédiatement disponibles lorsque le calcul reprend. |
| Branches instantanées | Créez une copie isolée et rédigible de votre base de données en quelques secondes. Parce que le branchement est une opération de copie sur écriture de métadonnées sur un stockage partagé, il ne duplique aucune donnée. |
| Lire les réplicas | Plusieurs instances de calcul sont lues depuis la même couche de stockage, donc les répliques n’ont pas besoin de copies de données et commencent en quelques secondes. |
| Requêtes au moment donné | Parce que la couche de stockage conserve l’historique, le calcul peut se connecter à un moment passé et lire la base de données telle qu’elle existait alors, sans recopier les données en place. |
| Basculement rapide | Le basculement favorise une instance de calcul secondaire qui se connecte au stockage existant, sans données à transférer. |
| RPO = 0 (aucune perte de données engagée) | Lakebase enregistre durablement chaque transaction engagée avant de la reconnaître, donc vous ne perdez aucune donnée engagée lorsque le calcul échoue, redémarre ou s’étale à zéro. |
Comment cette architecture supporte LTAP
Parce que Lakebase stocke durablement chaque changement engagé dans le stockage d’objets cloud, les mêmes données peuvent servir des charges de travail analytiques aux côtés des transactions sans pipeline de réplication séparé. C’est la base du traitement transactionnel et analytique (LTAP) de Lake, où une seule copie de vos données supporte à la fois des moteurs transactionnels et analytiques. Pour comprendre comment LTAP s’appuie sur cette architecture, voir architecture LTAP.
Étapes suivantes
- Architecture du stockage : Découvrez comment fonctionne la redondance de stockage et pourquoi elle est indépendante du réglage de haute disponibilité de calcul. Consultez l’architecture de stockage.
- Branches de bases de données : Voyez comment les branches utilisent le stockage copy-on-write pour créer des environnements instantanés et isolés. Voir Branches.
- Lisez les répliques : Ajoutez des instances de calcul en lecture seule qui partagent la même couche de stockage. Consultez réplicas en lecture.
- Concepts clés : Examinez l’ensemble complet des concepts qui rendent Lakebase unique. Voir Concepts fondamentaux.