Lakebase est une base de données Postgres entièrement gérée, conçue pour les réalités opérationnelles du développement d'applications modernes. Ce qui la distingue des autres fournisseurs de bases de données du marché proposant également un moteur Postgres, c'est son architecture sous-jacente, qui sépare le stockage et le calcul avec une couche de calcul serverless, ainsi que son intégration étroite avec le Lakehouse et la plateforme d'intelligence des données. Vous pouvez en savoir plus sur cette architecture et certains de ses avantages ici. Un avantage qui passe pourtant souvent inaperçu est que cette architecture rend également Lakebase extrêmement économique. Dans ce blog, nous allons détailler l'origine de ces économies et partager des conseils pratiques pour en tirer le meilleur parti.
Les branches de base de données permettent aux développeurs de créer des environnements isolés avec des données de production à des fins de développement, de test ou d'expérimentation. Contrairement aux approches qui nécessitent la création d'une copie physique distincte de la base de données pour chaque environnement, les branches Lakebase partagent le même stockage sous-jacent et suivent les modifications à mesure que la branche s'écarte de sa branche parente. Cela rend la création de branches particulièrement économique pour les environnements de développement et de test temporaires, où les équipes peuvent travailler avec des données similaires à celles de la production sans avoir à provisionner et à maintenir une copie complètement distincte de la base de données.
L'autoscaling ajuste activement les ressources de calcul de votre instance Lakebase en fonction des variations d'activité. Vous pouvez contrôler la plage minimale et maximale entre lesquelles l'instance peut s'adapter. Les avantages financiers de cette fonctionnalité sont évidents : la capacité de calcul s'adapte à la demande de la charge de travail au lieu d'être provisionnée de manière statique pour les pics d'utilisation.
Définir une taille maximale de calcul permet de rendre les coûts prévisibles, car vous évitez les dépenses imprévues en plafonnant la limite supérieure de vos coûts de calcul. Pendant les périodes de faible utilisation, vos ressources de calcul diminuent, ce qui réduit les coûts. Associé à la mise à l'échelle à zéro (scale to zero), le calcul est entièrement suspendu après une période d'inactivité, ce qui ramène les coûts de calcul à zéro. Le calcul reprend après une mise à l'échelle à zéro en quelques centaines de millisecondes. Cela le rend particulièrement attractif pour les scénarios qui ne sont pas extrêmement sensibles à la latence, tels que les flux de travail de développement, les variantes d'applications hors production et les applications de production qui n'ont pas besoin de latences à deux chiffres.
Lorsque la mise à l'échelle à zéro est désactivée, Lakebase propose une tarification toujours active (always on), qui correspond à une réduction de 25 % sur votre capacité de base. Cette réduction de coût s'applique également à tout calcul qui ne peut pas être mis à l'échelle à zéro, comme les configurations HA.
La séparation du stockage et du calcul de Lakebase rend également les réplicas de lecture et la haute disponibilité plus économiques. Les réplicas de lecture sont des instances de calcul indépendantes qui lisent à partir de la même couche de stockage sous-jacente que l'instance principale. Ainsi, l'augmentation de la capacité de lecture ne nécessite pas de créer et de payer une autre copie de la base de données. De même, la haute disponibilité ajoute du calcul redondant sur plusieurs zones de disponibilité tout en continuant d'utiliser la couche de stockage hautement disponible existante. Cela signifie que vous pouvez ajouter de l'échelle de lecture et de la redondance de calcul sans multiplier votre empreinte de stockage.
L'intégration étroite de Lakebase avec la plateforme plus large Databricks Intelligence Platform permet des synchronisations gérées entre les deux environnements. Les tables synchronisées affichent les données de Unity Catalog dans votre base de données Lakebase pour prendre en charge les lectures transactionnelles à faible latence pour les cas d'usage d'applications ou de service de fonctionnalités (feature serving).
Une erreur courante des clients consiste à pousser une grande table Delta dans Lakebase alors que l'application n'interroge qu'un sous-ensemble actif beaucoup plus restreint. Cela gonfle le stockage Lakebase, augmente les coûts de synchronisation et peut même entraîner des problèmes de performances dans certains scénarios. La solution est simple : ne synchronisez que l'ensemble de travail nécessaire à l'application. Définissez exactement les données dont votre application a besoin avec une vue matérialisée (Materialized View), par exemple une fenêtre glissante de 60 jours, et synchronisez uniquement cela. Les pipelines de synchronisation Lakebase peuvent utiliser le flux de données de modification automatique (automatic change data feed) de la MV pour calculer les modifications au niveau des lignes au moment de la lecture. Cela signifie que les modifications apportées à la MV, y compris les suppressions à mesure que les lignes sortent d'une fenêtre glissante, peuvent être propagées de manière incrémentielle dans Lakebase. Le résultat est un sous-ensemble actif récent et à faible latence dans Lakebase, tandis que l'historique complet reste dans Delta. Associez cela au mode de synchronisation le plus sobre qui répond à vos besoins, décrit ci-dessous, et vous obtenez un modèle d'ETL inverse (reverse ETL) bien plus économique.
Les tables synchronisées (Synced Tables) sont des pipelines déclaratifs Spark serverless (SDP) gérés en arrière-plan et s'exécutent pendant la durée de la synchronisation. Par conséquent, le coût de synchronisation dépend de facteurs tels que la quantité de données déplacées et la taille de l'instance Lakebase / les unités de capacité (CU).
Il existe trois modes de synchronisation différents pour déplacer des données du Lakehouse vers Lakebase, et il est important de faire correspondre le mode au niveau de fraîcheur réellement requis pour les données. Choisir le bon mode vous permet de répondre à vos exigences de latence tout en maîtrisant les coûts.
| Mode | Description | Idéal à utiliser quand |
|---|---|---|
| Snapshot | Copie de toutes les données | Les modifications de la source dépassent 10 % des lignes par cycle. Ce mode sera nettement plus rentable que le mode Triggered dans ces scénarios. |
| Triggered | Mises à jour incrémentielles qui s'exécutent à la demande ou à intervalles réguliers | Les lignes de la source changent selon un rythme connu. Les insertions, mises à jour et suppressions sont propagées à chaque actualisation. |
| Continuous | Streaming en temps réel avec une latence de quelques secondes | Les modifications doivent apparaître dans Lakebase en quasi-temps réel. Cela offre le délai le plus court pour un coût plus élevé. |
Source : Modes de synchronisation (Sync Modes)
Le mode Snapshot est l'option la plus économique pour les tables rarement mises à jour ou très volatiles, tandis que le mode Continuous peut être le plus coûteux car son pipeline fonctionne en continu et consomme du calcul même s'il n'y a pas de modifications à traiter. Le mode Snapshot est recommandé lorsque plus de 10 % des données sources changent entre les synchronisations, car il peut être jusqu'à 10 fois plus efficace. Pour les charges de travail incrémentielles, le mode Triggered offre l'équilibre idéal entre coût et latence. Vous pouvez obtenir une fraîcheur quasi continue à moindre coût en associant le mode Triggered à un déclencheur de mise à jour de table (table-update trigger), garantissant qu'il ne s'exécute que lorsque les données sources changent. En général, évitez les longs intervalles entre les exécutions, car un volume massif de modifications en attente peut rendre la synchronisation suivante lente et coûteuse.
Une autre optimisation utile des coûts est la possibilité de regrouper (binpack) plusieurs tables dans un seul pipeline de synchronisation. Si votre cas d'usage le permet, le même pipeline peut synchroniser les modifications de plusieurs tables Delta dans Lakebase, permettant à ces tables de partager le même calcul sous-jacent. Cela peut être particulièrement précieux pour les synchronisations en mode Continuous, où le pipeline fonctionne en permanence, car cela évite de payer pour des pipelines distincts fonctionnant en continu pour chaque table.
Lorsqu'un projet Lakebase est créé, il est automatiquement fourni avec une branche de production et un calcul principal en lecture-écriture. Par défaut, ce calcul est configuré pour effectuer un autoscaling entre 8 et 16 CU, avec une mise à l'échelle à zéro activée après 24 heures d'inactivité. Ces valeurs par défaut peuvent être tout à fait raisonnables pour votre charge de travail, mais si votre application nécessite moins de calcul, les laisser inchangées peut vous amener à payer pour plus de capacité que nécessaire.
Plutôt que de créer le projet et de penser à le redimensionner par la suite, vous pouvez définir la plage de calcul initiale lors du provisionnement programmatique du projet. Par exemple, en utilisant le SDK Databricks :
Si vous gérez Lakebase de manière déclarative avec les Declarative Automation Bundles (DABs), vous pouvez également définir la plage de calcul pour les points de terminaison (endpoints) que vous provisionnez :
Le facteur le plus important pour le dimensionnement est votre working set (ensemble de travail) : les données et les index auxquels votre application accède fréquemment, par opposition à la taille totale de votre base de données sur le disque. Une base de données de 2500 GB avec un working set actif de 20 GB n'a pas besoin de 2500 GB de RAM. Elle a seulement besoin d'assez de mémoire pour conserver ces 20 GB dans le cache, plus une marge de sécurité. Cela est important en raison de la façon dont la ressource de calcul utilise la mémoire. La RAM évolue de manière linéaire avec la taille de la ressource de calcul, et jusqu'à 75 % de la RAM d'une ressource de calcul est disponible en tant que cache de calcul. Lorsque votre working set tient dans ce cache, la grande majorité des lectures sont servies depuis la mémoire, de sorte qu'elles restent rapides et que leur latence reste constante. Lorsqu'il ne tient pas, Postgres doit récupérer les pages qui ne sont pas dans le cache à partir du stockage, ce qui est beaucoup plus lent qu'un accès mémoire et introduit une variabilité de latence que votre application ressentira. Le dimensionnement consiste donc en grande partie à choisir une ressource de calcul dont le cache dépasse votre working set, tout en laissant une marge de sécurité pour d'autres opérations. La mémoire n'est cependant pas la seule chose qui évolue avec la taille de la ressource de calcul. Prenez également en compte la complexité des requêtes, la simultanéité et vos objectifs de latence, car une charge de travail hautement simultanée ou sensible à la latence nécessite plus de marge de sécurité qu'un outil interne peu utilisé pour la même taille de données.
Les connexions à la base de données méritent également une attention particulière. max_connections, la limite stricte des connexions Postgres simultanées, est également déterminée par la taille de votre ressource de calcul, et pour une ressource de calcul avec mise à l'échelle automatique (autoscaling), elle suit une règle spécifique : la limite est définie par la plus petite valeur entre votre CU maximum et huit fois votre CU minimum. Augmenter le maximum ne permet donc d'ajouter des connexions que jusqu'à huit fois votre minimum, et au-delà de ce point, un minimum faible limite l'impact d'un maximum plus élevé. Une application qui ouvre un grand nombre de connexions peut atteindre ce plafond et commencer à rejeter les nouvelles connexions avec des erreurs. Si le volume de connexions est une réelle contrainte, intégrez-le dans votre CU minimum et placez un gestionnaire de pool de connexions (connection pooler) devant Lakebase. Un gestionnaire de pool permet à de nombreuses connexions clientes de partager un pool de connexions Postgres et prend en charge jusqu'à 10 000 connexions clientes simultanées. Le regroupement en pool (pooling) est généralement la bonne solution pour les applications qui ouvrent beaucoup de connexions, et cela coûte moins cher que d'augmenter la taille de la ressource de calcul uniquement pour relever le plafond de connexions.
Vous n'avez pas à deviner tout cela. Le tableau de bord Lakebase Metrics indique la taille de votre working set sur des fenêtres de 5 minutes, 15 minutes et 1 heure, et l'affiche directement à côté de votre cache de calcul disponible, afin que vous puissiez voir en un coup d'œil si vos données actives y tiennent. Consultez-le en parallèle avec le taux de réussite du cache (cache hit rate), l'utilisation du CPU, de la RAM et des connexions pour valider votre dimensionnement initial et l'ajuster à la hausse ou à la baisse. Pour les charges de travail avec des modèles d'accès stables, comparer le working set d'une heure au cache de calcul disponible est un signal particulièrement utile. La mise à l'échelle automatique (autoscaling) offre le plus d'avantages lorsque votre working set tient déjà en mémoire au CU minimum, car sinon vous payez une pénalité de cache froid à chaque fois que la ressource de calcul monte en charge. Utilisez ces métriques pour définir un minimum qui contient votre working set et un maximum qui absorbe vos pics.
Un sous-dimensionnement se manifeste rarement par une panne totale. Le plus souvent, il apparaît sous forme de symptômes faciles à mal diagnostiquer :
La restauration à un instant dans le passé (PITR) conserve en continu l'historique nécessaire pour restaurer votre base de données à n'importe quel moment dans une fenêtre de récupération configurable de 2 à 30 jours. Les snapshots, quant à eux, sont des captures ponctuelles discrètes d'une branche racine qui peuvent être créées manuellement ou selon un calendrier automatisé quotidien, hebdomadaire ou mensuel.
Le stockage PITR augmente à la fois avec l'activité d'écriture et la durée de votre fenêtre de récupération, car Lakebase doit conserver l'historique des modifications tout au long de cette période. Pour une application à forte intensité d'écriture, une longue fenêtre PITR peut entraîner une consommation de stockage importante. Une approche soucieuse des coûts consiste à choisir une fenêtre PITR qui répond à vos exigences de reprise après incident et à la compléter par des snapshots planifiés lorsque vous avez besoin de points de récupération à plus long terme.
La bonne nouvelle est que ces deux options sont facturées à un tarif inférieur à celui du stockage de branche Lakebase standard. Le stockage de snapshots (0,090 $/GB-mois) est environ 74 % moins cher que le stockage de branche standard, tandis que le stockage PITR (0,200 $/GB-mois) est environ 42 % moins cher. Les snapshots planifiés peuvent être particulièrement efficaces en termes de stockage : le premier snapshot d'un calendrier est stocké sous forme de snapshot complet, tandis que les snapshots suivants ne sont facturés que pour les modifications incrémentielles.
Utilisez la PITR pour vous remettre d'incidents inattendus tels que des suppressions accidentelles ou des écritures incorrectes qui pourraient survenir à tout moment dans votre fenêtre de récupération. Utilisez des snapshots pour des points de récupération planifiés. For example, prenez un snapshot manuel avant une migration risquée ou une mise à jour en bloc, et utilisez des snapshots planifiés pour une protection de routine à plus long terme.
En fin de compte, adaptez votre configuration de récupération à vos besoins réels. Conserver plus d'historique ou de points de récupération que nécessaire peut augmenter les coûts de stockage sans apporter de valeur ajoutée significative.
Comme indiqué ci-dessus, les coûts de Lakebase se répartissent en trois domaines : le calcul de la base de données, le stockage de la base de données et, lors de l'utilisation de Synced Tables, le calcul du pipeline serverless utilisé pour synchroniser les données du Lakehouse vers Lakebase.
Le calcul est mesuré en fonction de l'utilisation des CU au fil du temps. Avec la mise à l'échelle automatique (Autoscaling), l'utilisation suit la capacité de calcul consommée à mesure que la base de données s'adapte à l'échelle dans sa plage configurée.
Le stockage comprend le stockage de branche de base de données, l'historique de restauration à un instant dans le passé (PITR) et le stockage de snapshots. Ceux-ci sont mesurés séparément en fonction de leur utilisation de stockage sous-jacente.
Synced Tables utilise des pipelines gérés pour déplacer les données de Unity Catalog vers Lakebase. Le calcul du pipeline utilisé pour la synchronisation est facturé séparément du calcul de la base de données Lakebase.
L'utilisation du calcul et du stockage Lakebase est disponible dans system.billing.usage. L'utilisation du stockage peut être détaillée davantage à l'aide de product_features.lakebase.storage_type :
BRANCH_DATA_STORAGE : stockage pour les branches de base de données sans expirationBRANCH_CHANGE_STORAGE : données modifiées stockées pour les branches expirantBRANCH_HISTORY_STORAGE : historique conservé pour la PITRLa requête ci-dessous joint usage à system.billing.list_prices pour estimer le coût quotidien au prix catalogue effectif.
Lakebase expose des SKU de calcul et de stockage distincts dans les tables système de facturation, le champ de type de stockage fournissant la ventilation supplémentaire présentée ci-dessus.
Vous trouverez l'UID du projet dans l'interface utilisateur de Lakebase sous Projet > Paramètres > UID. Par programmation, si vous connaissez le nom du projet, listez les projets et effectuez une correspondance sur status.display_name pour récupérer son UID.
L'utilisation du pipeline de la table synchronisée peut également être interrogée à partir de system.billing.usage. Filtrez sur l'ID du pipeline sous-jacent et effectuez une jointure avec system.billing.list_prices pour estimer le coût quotidien du pipeline.
Ces requêtes estiment le coût en utilisant le prix catalogue effectif pour la période d'utilisation. Les remises contractuelles spécifiques au client ne sont pas prises en compte.
Vous pouvez trouver l'ID du pipeline en ouvrant la table synchronisée dans l'interface utilisateur et en copiant l'ID du pipeline. Par programmation, récupérez la table synchronisée et lisez status.pipeline_id :
Lakebase est conçu dès sa conception architecturale pour être rentable, du stockage partagé et du branching à la mise à l'échelle automatique et au calcul serverless. Associez ces gains d'efficacité intégrés à une configuration réfléchie en matière de dimensionnement, de stratégie de synchronisation et de récupération, et vous pourrez maintenir des coûts prévisibles tout en bénéficiant des performances, de la disponibilité et de l'expérience de développement dont vos applications ont besoin.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.