Une nouvelle ère pour les bases de données : Lakebase

Depuis des décennies, les bases de données sont l'épine dorsale des logiciels : alimentant discrètement tout, des flux de paiement du commerce électronique à la planification des ressources d'entreprise. Chaque élément de logiciel dans le monde, chaque application, chaque flux de travail, chaque ligne de code générée par l'IA dépend en fin de compte d'une base de données sous-jacente. Au fil du temps, nous avons complètement réinventé la façon dont les applications sont construites, mais les bases de données sous-jacentes ont très peu changé depuis les années 1980. Elles reposent en grande partie sur des architectures antérieures au cloud moderne et souffrent des problèmes suivants :

• Opérations fragiles et coûteuses : Les bases de données traditionnelles sont considérées comme l'un des éléments d'infrastructure les plus délicats, et leur exploitation fiable nécessite généralement une armée de spécialistes pour « marcher sur des œufs ». Elles regroupent le calcul et le stockage dans une unité monolithique rigide. Cela oblige les équipes à provisionner pour la capacité de pointe, ce qui entraîne des ressources inactives coûteuses. Lorsque la charge dépasse la capacité provisionnée, les bases de données peuvent devenir non réactives. Pire encore, des tâches de maintenance simples comme la création d'un instantané d'une base de données ou l'exécution d'une requête de nettoyage GDPR peuvent potentiellement faire tomber toute la base de données.
• Expérience de développement maladroite : Les bases de données traditionnelles sont en conflit avec les flux de travail de développement modernes et agiles. Pour le code, il faut moins d'une seconde pour créer une branche git pour le développement qui est un clone entièrement isolé de la base de code. Pour les bases de données, il faut de nombreuses minutes, voire des heures, pour en provisionner une, et la création d'un clone haute fidélité de la base de données de production est très coûteuse et risque de faire tomber la base de données de production. L'essor du développement basé sur l'IA n'a fait qu'intensifier cette pression. Les agents d'IA doivent créer instantanément des environnements temporaires et isolés pour l'expérimentation.
• Verrouillage extrême du fournisseur : Les migrations de bases de données sont l'un des projets techniques les plus effrayants dans toute organisation. L'architecture monolithique signifie que la seule façon de faire entrer ou sortir des données est par le biais du moteur de base de données lui-même. Cela impose un verrouillage important du fournisseur, rendant les organisations profondément dépendantes du fournisseur spécifique.

Il est temps que les bases de données évoluent.

Qu'est-ce qu'une Lakebase ?

De nouveaux systèmes commencent à émerger qui répondent aux limitations des bases de données traditionnelles. Une Lakebase est une nouvelle architecture ouverte qui combine les meilleurs éléments des bases de données transactionnelles avec la flexibilité et l'économie du lac de données. Les Lakebases sont rendues possibles par une conception fondamentalement nouvelle : la séparation du calcul du stockage et le placement des données de la base de données directement dans le stockage cloud à faible coût (« lac ») dans des formats ouverts, tout en permettant à la couche de calcul transactionnel de fonctionner indépendamment au-dessus.

Cette séparation est la percée essentielle. Les bases de données traditionnelles regroupent le CPU et le stockage dans un seul système monolithique qui doit être provisionné, géré et payé comme une seule grande machine. Lakebase divise ces couches. Les données vivent ouvertement dans le lac, tandis que le moteur de base de données devient une couche de calcul serverless entièrement gérée (par exemple, Postgres) qui peut évoluer instantanément. Cette architecture élimine une grande partie des coûts, de la complexité et du verrouillage qui ont défini les bases de données pendant des décennies, et elle est particulièrement puissante pour les charges de travail modernes basées sur l'IA et les agents, où les développeurs veulent lancer de nombreuses instances, expérimenter librement et ne payer que ce qu'ils utilisent.

Une Lakebase possède les caractéristiques clés suivantes :

Le stockage est séparé du calcul : Les données sont stockées à moindre coût dans des magasins d'objets cloud (« lac »), tandis que le calcul s'exécute indépendamment et de manière élastique. Cela permet une mise à l'échelle massive, une concurrence élevée et la possibilité de réduire l'échelle jusqu'à zéro en moins d'une seconde (ce qui n'est pas possible dans les systèmes de base de données hérités), éliminant ainsi le besoin de maintenir des machines de base de données coûteuses en fonctionnement au ralenti.

Stockage illimité, à faible coût et durable : Avec les données vivant dans le lac, le stockage devient essentiellement infini et considérablement moins cher que les systèmes de base de données traditionnels qui nécessitent une infrastructure à capacité fixe. Et son stockage est soutenu par la durabilité du stockage d'objets cloud (par exemple, S3), offrant une durabilité de 99,999999999 % par défaut. Ceci est de loin supérieur à la configuration de base de données traditionnelle consistant à avoir des répliques pour la redondance du stockage (le plus souvent mises à jour de manière asynchrone, ce qui signifie qu'il existe un risque de perte de données dans de nombreuses configurations en cas de double panne).

Calcul Postgres élastique et serverless : Lakebase fournit Postgres entièrement géré et serverless qui évolue instantanément avec la demande et diminue en cas d'inactivité. Les coûts s'alignent directement sur l'utilisation, ce qui le rend idéal pour les charges de travail en rafale, les environnements de développement et les agents d'IA créant des instances temporaires.

Branchement, clonage et récupération instantanés : Les bases de données peuvent être branchées et clonées de la même manière que les développeurs branchent le code. Même les bases de données à l'échelle du pétaoctet peuvent être copiées en quelques secondes, ce qui permet une expérimentation rapide, des restaurations sûres et une restauration instantanée sans surcharge opérationnelle.

Charges de travail transactionnelles et analytiques unifiées : Lakebase s'intègre de manière transparente à Lakehouse, partageant la même couche de stockage entre OLTP et OLAP. Cela permet d'exécuter des analyses en temps réel, de l'apprentissage automatique et une optimisation basée sur l'IA directement sur les données transactionnelles sans les déplacer ni les dupliquer.

Ouvert et multicloud par conception : Les données stockées dans des formats ouverts évitent le verrouillage propriétaire et permettent une véritable portabilité sur AWS, Azure et au-delà. La flexibilité multicloud intégrée prend en charge la reprise après sinistre, la liberté à long terme et une économie plus forte au fil du temps.

Ce sont les principaux attributs de Lakebase. Les systèmes transactionnels de qualité entreprise nécessitent des capacités supplémentaires telles que la sécurité, la gouvernance, l'audit et la haute disponibilité, mais avec une Lakebase, ces fonctionnalités ne doivent être mises en œuvre et gérées qu'une seule fois, sur une seule base ouverte. Lakebase représente la prochaine évolution des bases de données : des systèmes transactionnels reconstruits pour le cloud, pour les développeurs et pour l'ère de l'IA.

Évolution de l'architecture de la base de données

Pour comprendre pourquoi une nouvelle ère est nécessaire, il est utile d'examiner comment l'architecture de la base de données a évolué au cours des cinquante dernières années. Nous considérons cette évolution en trois générations distinctes :

Génération 1 : Monolithe

Exemples : MySQL, Postgres, Oracle classique

Les systèmes de base de données ont commencé comme des monolithes absolus. À l'ère pré-cloud, le réseau était la partie la plus lente de tout système. La seule façon de concevoir une base de données haute performance était de lier étroitement le calcul (CPU/RAM) et le stockage (disque) à l'intérieur d'une seule machine physique. Bien que cela ait du sens pour les limitations matérielles des années 1980, cela a créé une cage rigide où les données étaient piégées dans des formats propriétaires et la mise à l'échelle signifiait l'achat d'une boîte plus grande.

Génération 2 : Couplage lâche propriétaire du stockage

Exemples : Aurora, Oracle Exadata

À mesure que l'infrastructure cloud s'améliorait, les fournisseurs ont physiquement séparé le stockage du calcul, déplaçant le stockage dans des niveaux backend propriétaires. Ces systèmes étaient des merveilles d'ingénierie qui repoussaient les limites du débit. Cependant, ils ne sont pas allés assez loin. La séparation était purement une optimisation interne. Étant donné que les données restent enfermées dans un format propriétaire accessible uniquement par un seul moteur, les systèmes de génération 2 souffrent d'impasses structurelles :

• Étranglement du moteur unique : Les données sont accessibles uniquement via le moteur de base de données principal, qui devient le goulot d'étranglement. Il est difficile pour les agents d'IA ou les moteurs analytiques d'accéder aux données à grande échelle.
• Friction analytique : Étant donné que vous ne pouvez pas avoir de moteurs OLAP distincts accédant directement aux fichiers de base de données à grande échelle, l'exécution de requêtes analytiques reste difficile et nécessite généralement un ETL complexe pour extraire les données.
• Verrouillage cloud : La couche de stockage est souvent étroitement couplée à l'infrastructure propriétaire du fournisseur de cloud spécifique. Cela rend l'interopérabilité multicloud difficile et rend impossible la véritable haute disponibilité et la reprise après sinistre (HADR) entre les clouds. Si la région du fournisseur échoue, vos données sont bloquées.

Nous pensons que ces systèmes sont dans un état de transition vers la 3e génération ultime.

Génération 3 : Lakebase - Stockage ouvert sur le lac

Une Lakebase pousse l'architecture découplée à sa conclusion logique ultime. Comme la génération 2, elle sépare le calcul du stockage, mais avec une différence essentielle : l'infrastructure de stockage et les formats de données sont complètement ouverts.

S'appuyant sur cette architecture, elle peut résoudre les 3 défis susmentionnés :

• Meilleure fiabilité et coût inférieur grâce à des opérations plus simples : Les opérations courantes telles que le provisionnement, la mise à l'échelle, la réduction d'échelle, le branchement, la création d'instantanés, la récupération peuvent être effectuées en quelques secondes. Les requêtes coûteuses peuvent être exécutées sur différentes instances de calcul élastiques sans affecter le trafic de production.
• Expérience de développeur de type Git : Il devient plus rapide d'expérimenter et de développer des applications, basées sur une branche haute fidélité des bases de données de production. Pour les développeurs et les agents d'IA, cela signifie que la base de données évolue aussi rapidement que leur code.
• Résout le verrouillage extrême du fournisseur : Avec les données dans des formats ouverts stockées dans des magasins d'objets cloud, vous êtes beaucoup moins verrouillé. Vous possédez vos données, indépendamment du moteur.

À bien des égards, une Lakebase est ce que vous construiriez si vous deviez repenser les bases de données OLTP aujourd'hui, maintenant que le stockage d'objets fiable et bon marché et l'élasticité du cloud sont disponibles. À mesure que les organisations évoluent plus rapidement en adoptant le cloud et l'IA, nous nous attendons à ce que ce modèle devienne une base standard pour la construction de systèmes transactionnels.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original