HyperAIHyperAI

Command Palette

Search for a command to run...

il y a un jour

Databricks et Neon : l'architecture Lakebase et LTAP

Le développement de Lakebase, une nouvelle architecture de base de données conçue par les équipes de Databricks et Neon, redéfinit la conception des systèmes de traitement transactionnel. Contrairement aux bases monolithiques traditionnelles, où le calcul et le stockage sont intimement couplés, Lakebase les sépare radicalement pour résoudre les défis persistants en matière d'évolutivité, de durabilité et de contention des charges de travail. Dans les architectures classiques, les données et le journal des modifications résident sur le même disque physique. Cette configuration expose les systèmes aux risques de perte de données en cas de panne matérielle, complique la mise à l'échelle des lectures parallèles et fait s'interférer les requêtes analytiques avec les transactions critiques. Lakebase contourne ces limites en externalisant le journal vers SafeKeeper, un service distribué qui garantit la durabilité via une réplication réseau synchrone, et en déplaçant les fichiers de données vers PageServer. Ce dernier interagit directement avec un stockage objet cloud tout en maintenant un cache local agressif pour préserver des latences de lecture comparables à une installation physique. Cette séparation des responsabilités libère plusieurs avantages opérationnels majeurs. Le calcul devient sans état, élastique et capable de passer à zéro lorsqu'il est inutilisé, optimisant ainsi les coûts informatiques. La haute disponibilité est simplifiée, car l'état durable est entièrement indépendant des instances de calcul. Surtout, le clonage ou la création de branches de bases de données passe d'une opération lente et risquée à une tâche instantanée, similaire à la gestion des versions dans le développement logiciel. L'équipe a récemment annoncé le déploiement de LTAP, pour Lake Transactional and Analytical Processing, une innovation qui unifie le traitement transactionnel et analytique sans recourir à la duplication des données. Au lieu d'utiliser des pipelines de réplication ou de transformation continus, souvent sujets aux délais et aux ruptures de synchronisation, LTAP convertit automatiquement les données de leur format ligne natif vers un format colonne ouvert directement au niveau du stockage. Cette approche permet à Postgres et aux moteurs analytiques lakehouse de lire simultanément un seul jeu de données gouverné. La conversion s'effectue au repos, sans impacter la charge transactionnelle. Le système préserve également les fonctionnalités avancées comme l'isolation par instantané et la récupération à un point dans le temps, tout en exposant aux outils analytiques des tables cohérentes et actualisées en temps réel. Contrairement aux architectures HTAP qui tentent d'unifier le traitement au niveau du moteur logiciel, souvent au détriment des fonctionnalités et de la maturité de l'écosystème, LTAP opte pour une unification au niveau du stockage. Cette stratégie garantit une isolation complète des performances, une compatibilité avec les écosystèmes techniques existants et une simplification structurelle des infrastructures. Le déploiement progressif de cette technologie vise à réduire la complexité de gestion des données, à diminuer les coûts de stockage et à éliminer les frictions entre les systèmes opérationnels et analytiques.

Liens associés