Lakebase es una base de datos Postgres totalmente administrada, diseñada para las realidades operativas del desarrollo de aplicaciones modernas. Lo que la diferencia de otros proveedores de bases de datos del mercado que también ofrecen un motor Postgres es su arquitectura subyacente: almacenamiento y cómputo separados con una capa de cómputo serverless, y su estrecha integración con el Lakehouse y la plataforma de inteligencia de datos. Puedes leer más sobre esta arquitectura y algunos de sus beneficios aquí. Sin embargo, un beneficio que suele pasar desapercibido es que esta arquitectura también hace que Lakebase sea altamente eficiente en costos. En este blog, analizaremos de dónde provienen esas eficiencias de costos y compartiremos consejos prácticos para aprovecharlas al máximo.
Las ramas de base de datos permiten a los desarrolladores crear entornos aislados con datos de producción para fines de desarrollo, pruebas o experimentación. A diferencia de los enfoques que requieren crear una copia física independiente de la base de datos para cada entorno, las ramas de Lakebase comparten el mismo almacenamiento subyacente y realizan un seguimiento de los cambios a medida que la rama diverge de su elemento primario. Esto hace que la creación de ramas sea especialmente eficiente en costos para entornos de desarrollo y pruebas de corta duración, donde los equipos pueden trabajar con datos similares a los de producción sin necesidad de aprovisionar y mantener una copia de la base de datos completamente independiente.
El escalado automático cambia activamente los recursos de cómputo de tu instancia de Lakebase en respuesta a los diferentes niveles de actividad. Puedes controlar el rango mínimo y máximo entre los que se puede escalar la instancia. Los beneficios de costo de esta función son claros: la capacidad de cómputo puede escalarse según la demanda de la carga de trabajo en lugar de aprovisionarse de forma estática para el uso máximo.
Establecer un tamaño máximo de cómputo ayuda a que los costos sean predecibles, ya que evitas gastos inesperados al limitar el límite superior de tus costos de cómputo. Durante los momentos de poco uso, tu cómputo se reduce, lo que disminuye los costos. Cuando se combina con el escalado a cero, el cómputo se suspende por completo después de un período de inactividad, lo que reduce los costos de cómputo a cero. El cómputo se reanuda desde el escalado a cero en unos pocos cientos de milisegundos. Esto lo hace especialmente atractivo para escenarios que no son excepcionalmente sensibles a la latencia, como los flujos de trabajo de desarrollo, las variantes de aplicaciones que no son de producción y las aplicaciones de producción que no necesitan latencias de dos dígitos.
Cuando el escalado a cero está desactivado, Lakebase tiene una tarifa de siempre activo, que ofrece un 25% de descuento en tu capacidad de referencia. Esta reducción de costos también se aplica a cualquier cómputo que no pueda escalarse a cero, como las configuraciones de HA.
La separación de almacenamiento y cómputo de Lakebase también hace que las réplicas de lectura y la alta disponibilidad sean más eficientes en costos. Las réplicas de lectura son instancias de cómputo independientes que leen desde la misma capa de almacenamiento subyacente que la primaria, por lo que escalar la capacidad de lectura no requiere crear ni pagar por otra copia de la base de datos. De manera similar, la alta disponibilidad agrega cómputo redundante en todas las zonas de disponibilidad mientras continúa utilizando la capa de almacenamiento de alta disponibilidad existente. Esto significa que puedes agregar escala de lectura y redundancia de cómputo sin multiplicar tu huella de almacenamiento.
La estrecha integración de Lakebase con la plataforma de inteligencia de datos de Databricks más amplia permite sincronizaciones administradas entre los dos entornos. Las tablas sincronizadas muestran datos de Unity Catalog en tu base de datos de Lakebase para admitir lecturas transaccionales de baja latencia para casos de uso de aplicaciones o de servicio de características.
Un error común que cometen los clientes es enviar una tabla Delta grande a Lakebase cuando la aplicación solo consulta un subconjunto activo mucho más pequeño. Esto infla el almacenamiento de Lakebase, aumenta los costos de sincronización e incluso puede provocar problemas de rendimiento en algunos escenarios. La solución es simple: sincroniza solo el conjunto de trabajo necesario para la aplicación. Define exactamente los datos que necesita tu aplicación con una vista materializada (MV), por ejemplo, una ventana móvil de 60 días, y sincroniza solo eso. Las canalizaciones de sincronización de Lakebase pueden usar la fuente de datos de cambio automática de la MV para calcular los cambios a nivel de fila en el momento de la lectura. Esto significa que los cambios en la MV, incluidas las eliminaciones a medida que las filas envejecen fuera de una ventana móvil, se pueden propagar de forma incremental en Lakebase. El resultado es un subconjunto activo fresco y de baja latencia en Lakebase, mientras que el historial completo permanece en Delta. Combina esto con el modo de sincronización más eficiente que cumpla con tus requisitos, que se detalla a continuación, y tendrás un patrón de ETL inverso mucho más eficiente en costos.
Las tablas sincronizadas son canalizaciones declarativas de Spark serverless (SDP) administradas de forma interna y se ejecutan durante la sincronización. Por lo tanto, el costo de sincronización se ve impulsado por factores como la cantidad de datos que se mueven y el tamaño de la instancia de Lakebase o las unidades de capacidad (CU).
Existen tres modos de sincronización diferentes para mover datos desde el Lakehouse a Lakebase, y es importante adaptar el modo a la frescura real que requieran los datos. Elegir el modo correcto te permite cumplir con tus requisitos de latencia mientras mantienes los costos bajo control.
| Modo | Descripción | Mejor uso cuando |
|---|---|---|
| Snapshot | Copia de todos los datos | Los cambios en el origen son >10% de las filas por ciclo. Será sustancialmente más rentable que el modo Triggered en esos escenarios. |
| Triggered | Actualizaciones incrementales que se ejecutan bajo demanda o a intervalos | Las filas de origen cambian con una cadencia conocida. Las inserciones, actualizaciones y eliminaciones se propagan en cada actualización. |
| Continuous | Transmisión en tiempo real con segundos de latencia | Los cambios deben aparecer en Lakebase casi en tiempo real. Esto proporciona el menor retraso al mayor costo. |
Origen: Modos de sincronización
Snapshot es la opción más rentable para tablas que se actualizan con poca frecuencia o que son muy volátiles, mientras que Continuous puede ser la más costosa porque su canalización se ejecuta continuamente y consume cómputo incluso cuando no hay cambios que procesar. Se recomienda el modo Snapshot cuando cambia más del 10% de los datos de origen entre sincronizaciones, ya que puede ser hasta 10 veces más eficiente. Para cargas de trabajo incrementales, el modo Triggered ofrece el equilibrio ideal entre costo y latencia. Puedes lograr una frescura casi continua con un presupuesto limitado al combinar el modo Triggered con un desencadenador de actualización de tabla, lo que garantiza que se ejecute solo cuando cambien los datos de origen. En general, evita intervalos largos entre ejecuciones, ya que una acumulación masiva de cambios puede hacer que la sincronización posterior sea lenta y costosa.
Otra optimización de costos útil es la capacidad de empaquetar (binpack) o agrupar varias tablas en una sola canalización de sincronización. Si tu caso de uso lo permite, la misma canalización puede sincronizar cambios de varias tablas Delta en Lakebase, lo que permite que esas tablas compartan el mismo cómputo subyacente. Esto puede ser especialmente valioso para las sincronizaciones de tipo Continuous, donde la canalización siempre está en ejecución, porque evita pagar por canalizaciones independientes en ejecución continua para cada tabla.
Cuando se crea un proyecto de Lakebase, este incluye automáticamente una rama de producción y un cómputo de lectura y escritura principal. De forma predeterminada, ese cómputo está configurado para escalarse automáticamente entre 8 y 16 CU, con el escalado a cero habilitado después de 24 horas de inactividad. Es posible que esos valores predeterminados sean perfectamente razonables para tu carga de trabajo, pero si tu aplicación requiere menos cómputo, dejarlos sin cambios puede significar pagar por más capacidad de la que necesitas.
En lugar de crear el proyecto y recordar cambiar su tamaño después, puedes establecer el rango de cómputo inicial al aprovisionar el proyecto de forma programática. Por ejemplo, utilizando el SDK de Databricks:
Si administras Lakebase de forma declarativa con Declarative Automation Bundles (DABs), puedes definir de manera similar el rango de cómputo para los endpoints que aprovisionas:
El factor más importante para el dimensionamiento es su conjunto de trabajo: los datos e índices a los que su aplicación accede con frecuencia, a diferencia del tamaño total de su base de datos en disco. Una base de datos de 2500 GB con un conjunto de trabajo activo de 20 GB no necesita 2500 GB de RAM. Solo necesita memoria suficiente para mantener almacenados en caché esos 20 GB, más un margen adicional. Esto es importante debido a cómo el recurso de computación utiliza la memoria. La RAM se escala linealmente con el tamaño del recurso de computación, y hasta el 75% de la RAM de un recurso de computación está disponible como su caché de computación. Cuando su conjunto de trabajo cabe en esa caché, la gran mayoría de las lecturas se realizan desde la memoria, por lo que siguen siendo rápidas y su latencia se mantiene constante. Cuando no cabe, Postgres tiene que recuperar del almacenamiento las páginas que no están en la caché, lo cual es mucho más lento que un acceso a memoria e introduce la variabilidad de latencia que experimentará su aplicación. Por lo tanto, el dimensionamiento consiste en gran medida en elegir un recurso de computación cuya caché supere su conjunto de trabajo, dejando también un margen adicional para otras operaciones. Sin embargo, la memoria no es lo único que se escala con el tamaño del recurso de computación. Evalúe también la complejidad de las consultas, la concurrencia y sus objetivos de latencia, ya que una carga de trabajo con alta concurrencia o sensible a la latencia necesita más margen adicional que una herramienta interna de poco uso con el mismo tamaño de datos.
Las conexiones a la base de datos también merecen especial atención. max_connections, el límite estricto de conexiones simultáneas de Postgres, también se determina por el tamaño de su recurso de computación, y para un recurso de computación con escalado automático sigue una regla específica: el límite se establece mediante el valor menor entre su CU máximo y ocho veces su CU mínimo. Por lo tanto, aumentar el máximo solo añade conexiones hasta ocho veces su mínimo, y más allá de ese punto, un mínimo pequeño limita el alcance de un máximo mayor. Una aplicación que abre una gran cantidad de conexiones puede alcanzar este límite y comenzar a rechazar nuevas conexiones con errores. Si el volumen de conexiones es una limitación real, téngalo en cuenta en su CU mínimo y coloque un pooler de conexiones frente a Lakebase. Un pooler permite que muchas conexiones de clientes compartan un grupo de conexiones de Postgres y admite hasta 10,000 conexiones de clientes simultáneas. El uso de un pooler suele ser la respuesta adecuada para las aplicaciones que abren muchas conexiones, y es más económico que aumentar el tamaño del recurso de computación únicamente para elevar el límite de conexiones.
No tiene que adivinar nada de esto. El panel de métricas de Lakebase informa el tamaño de su conjunto de trabajo en ventanas de 5 minutos, 15 minutos y 1 hora, y lo muestra directamente junto a su caché de computación disponible, para que pueda ver de un vistazo si sus datos activos caben. Consúltelo junto con la tasa de aciertos de caché, el uso de CPU, RAM y la utilización de conexiones para validar su dimensionamiento inicial y ajustarlo hacia arriba o hacia abajo. Para cargas de trabajo con patrones de acceso estables, comparar el conjunto de trabajo de 1 hora con la caché de computación disponible es una señal especialmente útil. El escalado automático ofrece el mayor beneficio cuando su conjunto de trabajo ya cabe en la memoria con el CU mínimo, porque de lo contrario pagará una penalización por caché fría cada vez que el recurso de computación se escale hacia arriba. Utilice estas métricas para establecer un mínimo que contenga su conjunto de trabajo y un máximo que absorba sus picos.
El subdimensionamiento rara vez se presenta como un fallo absoluto. Con mayor frecuencia aparece como síntomas que son fáciles de diagnosticar erróneamente:
La restauración a un punto en el tiempo (PITR) mantiene continuamente el historial necesario para restaurar su base de datos a cualquier momento dentro de una ventana de recuperación configurable de 2 a 30 días. Los Snapshots, por otro lado, son capturas discretas en un punto en el tiempo de una rama raíz que se pueden crear manualmente o mediante una programación automatizada diaria, semanal o mensual.
El almacenamiento de PITR crece tanto con la actividad de escritura como con la duración de su ventana de recuperación, ya que Lakebase debe conservar el historial de cambios durante ese período. Para una aplicación con un alto volumen de escritura, una ventana de PITR prolongada puede generar un consumo de almacenamiento significativo. Un enfoque consciente de los costos consiste en elegir una ventana de PITR que cumpla con sus requisitos de recuperación ante incidentes y complementarla con snapshots programados cuando necesite puntos de recuperación a más largo plazo.
La buena noticia es que ambos tienen un precio inferior al del almacenamiento normal de ramas de Lakebase. El almacenamiento de snapshots ($0.090/GB al mes) es aproximadamente un 74% más económico que el almacenamiento de ramas normal, mientras que el almacenamiento de PITR ($0.200/GB al mes) es alrededor de un 42% más barato. Los snapshots programados pueden ser especialmente eficientes en cuanto al almacenamiento: el primer snapshot de una programación se almacena como un snapshot completo, mientras que los snapshots posteriores solo se cobran por los cambios incrementales.
Utilice PITR para recuperarse de incidentes inesperados, como eliminaciones accidentales o escrituras incorrectas que podrían ocurrir en cualquier momento dentro de su ventana de recuperación. Utilice snapshots para puntos de recuperación planificados. Por ejemplo, realice un snapshot manual antes de una migración de riesgo o una actualización masiva, y utilice snapshots programados para una protección rutinaria a más largo plazo.
En última instancia, adapte su configuración de recuperación a sus requisitos reales de recuperación. Conservar más historial o puntos de recuperación de los necesarios puede aumentar los costos de almacenamiento sin aportar un valor adicional significativo.
Como se mencionó anteriormente, los costos de Lakebase se dividen en tres áreas: computación de la base de datos, almacenamiento de la base de datos y, cuando se utilizan Synced Tables, la computación de canalización serverless utilizada para sincronizar datos desde el Lakehouse hacia Lakebase.
Compute se mide en función del uso de CU a lo largo del tiempo. Con el escalado automático (Autoscaling), el uso sigue la capacidad de computación consumida a medida que la base de datos se escala dentro de su rango configurado.
Storage incluye el almacenamiento de ramas de la base de datos, el historial de restauración a un punto en el tiempo (PITR) y el almacenamiento de snapshots. Estos se miden por separado en función de su uso de almacenamiento subyacente.
Synced Tables utiliza canalizaciones administradas para mover datos desde Unity Catalog hacia Lakebase. La computación de la canalización utilizada para la sincronización se factura por separado de la computación de la base de datos de Lakebase.
El uso de computación y almacenamiento de Lakebase está disponible en system.billing.usage. El uso de almacenamiento se puede desglosar aún más utilizando product_features.lakebase.storage_type:
BRANCH_DATA_STORAGE: almacenamiento para ramas de bases de datos que no caducanBRANCH_CHANGE_STORAGE: datos modificados almacenados para ramas que caducanBRANCH_HISTORY_STORAGE: historial conservado para PITRLa siguiente consulta une usage con system.billing.list_prices para estimar el costo diario al precio de lista vigente.
Lakebase expone SKU de cómputo y almacenamiento independientes en las tablas del sistema de facturación, y el campo de tipo de almacenamiento proporciona el desglose adicional que se muestra arriba.
Puedes encontrar el UID del proyecto en la interfaz de usuario de Lakebase en Proyecto > Configuración > UID. De manera programática, si conoces el nombre del proyecto, enumera los proyectos y busca la coincidencia en status.display_name para recuperar su UID.
El uso de las canalizaciones de Synced Table también se puede consultar desde system.billing.usage. Filtra por el ID de la canalización subyacente y únelo a system.billing.list_prices para estimar el costo diario de la canalización.
Estas consultas estiman el costo utilizando el precio de lista vigente para el período de uso. No se reflejan los descuentos contractuales específicos del cliente.
Puedes encontrar el ID de la canalización abriendo la Synced Table en la interfaz de usuario y copiando el ID de la canalización. De manera programática, recupera la Synced Table y lee status.pipeline_id:
Lakebase está diseñado para ser rentable desde su arquitectura, desde el almacenamiento compartido y la ramificación hasta el escalado automático y el cómputo serverless. Combina esas eficiencias integradas con una configuración bien planificada en torno al dimensionamiento, la estrategia de sincronización y la recuperación, y podrás mantener los costos predecibles al tiempo que obtienes el rendimiento, la disponibilidad y la experiencia de desarrollo que tus aplicaciones necesitan.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.