Conozca Dynamic PostgreSQL: la evolución natural de las bases de datos en la nube

Empezando hoy, puedes crear bases de datos dinámicas de PostgreSQL en escala de tiempo .

Dynamic PostgreSQL es la evolución natural de las bases de datos en la nube, que resuelve los problemas tanto de las bases de datos aprovisionadas como de las bases de datos sin servidor. Está respaldado por computación dinámica, una innovación de escala de tiempo que escala instantáneamente su computación disponible dentro de un rango mínimo/máximo predefinido según su carga. En lugar de aprovisionarse para su pico (y pagar por ello en todo momento), ahora puede elegir un rango de cómputo: su base de datos funcionará a su capacidad base y accederá instantáneamente hasta su pico solo cuando sea necesario. Compra la base, alquila el pico.

Esto da como resultado una relación precio-rendimiento incomparable: los clientes que ejecutan cargas de trabajo de producción ahorrarán entre un 10 % y un 20 % al migrar desde AWS RDS para PostgreSQL y entre un 50 % y un 70 % al migrar desde AWS Aurora Serverless.

Puede probar Dynamic PostgreSQL hoy. Ofrecemos una prueba gratuita (no se requiere tarjeta de crédito) que le brinda acceso completo a la plataforma durante 30 días.

Para crear un servicio PostgreSQL dinámico, simplemente seleccione la opción PostgreSQL al iniciar sesión en Timescale:

Su aplicación está siempre activa, ¿por qué no debería estarlo su base de datos?

Bienvenido al futuro.

Problema 1: los desarrolladores suministran mucha más computación de la que necesitan

Durante los últimos años, desde que lanzamos Timescale por primera vez, hemos estado en primera fila sobre cómo los desarrolladores usan las bases de datos. Por ejemplo, sólo en los últimos meses, Hemos analizado más de un billón de consultas. como parte de nuestro producto Insights.

Una cosa que hemos aprendido es que los desarrolladores a menudo suministran mucha más computación de la que realmente necesitan.

Por un lado, esto tiene sentido: nunca querrás preocuparte por tu base de datos. La mayoría de las cargas de trabajo de bases de datos son continuas, normalmente con cierta variabilidad o ráfagas. Por ejemplo, un juego que se usa más por la noche, una aplicación empresarial que se usa más durante el día o un dispositivo doméstico conectado que se usa más los fines de semana que durante la semana.

Nunca querrás que tu base de datos se quede sin recursos. Si su base de datos está a su máxima capacidad, eso conduce a una experiencia de cliente terrible (¡o ninguna experiencia de cliente!). Por lo tanto, la mayoría de los desarrolladores terminan aprovisionando el pico, además de un buffer. Esto da como resultado que los desarrolladores paguen por mucha más computación de la que realmente necesitan.

Por otro lado, esto nos parece una locura. ¿Qué otro recurso empresarial estaría bien que las organizaciones gastaran mucho más de lo que necesitan? Computación desperdiciada equivale a dinero desperdiciado.

Problema 2: las bases de datos sin servidor no son suficientes para las cargas de trabajo de producción

Algunos de ustedes se preguntarán: "¿Qué pasa con las bases de datos sin servidor?"

El concepto sin servidor se originó con cargas de trabajo sin estado. Después del éxito de las máquinas virtuales en la nube, donde los usuarios podían dejar de preocuparse por el hardware, se preguntaron por qué preocuparse siquiera por ejecutar servidores de aplicaciones. Después de todo, muchos usuarios solo querían ejecutar funciones y solo se les cobraría por el tiempo que esas funciones estuvieran ejecutándose. Y es fácil y fluido activar funciones según sea necesario, casi precisamente porque no tienen estado. La tecnología sin servidor (y la función como servicio o FaaS) se convirtió en un éxito, con AWS Lambda tomando el relevo.

Entonces los desarrolladores se preguntaron: "¿Por qué pagar por mi base de datos cuando no la estoy usando?" La pregunta real es buena: los recursos desperdiciados son un problema masivo de bases de datos. Y la práctica de aprovisionar una base de datos AWS RDS en una instancia de servidor específica (digamos, un db.m6gd.2xlarge) seguramente no parece moderna ni flexible: CPU fija, memoria fija, disco local fijo. La mayor parte está infrautilizada la mayor parte del tiempo.

Pero aquí es donde las cosas se complican: las bases de datos son muy diferentes de las funciones Lambda.

Las bases de datos sin servidor actuales son incorrectas para la mayoría de las cargas de trabajo de producción por dos razones principales:

• Las bases de datos sin servidor se centran en los extremos para ampliar y reducir, incluso hasta cero.

• Las bases de datos sin servidor introducen precios mucho más altos para tener en cuenta el “espacio libre” de recursos reservado para satisfacer las demandas cambiantes (y peor, a menudo con modelos de precios que son difíciles de entender o predecir).

  
  

Comencemos discutiendo el tema candente de la "escala a cero". La realidad es que la mayoría de las bases de datos de producción no necesitan ni se beneficiarán del escalamiento a cero.

Ahora bien, hay algunos casos de uso en los que “escalar a cero” tiene sentido. Por ejemplo, demostraciones de prueba de concepto o aplicaciones más para aficionados. La capacidad de ejecutar ocasionalmente una consulta ad hoc en su conjunto de datos (AWS Athena y Google BigQuery son argumentos sólidos a favor de un almacén de datos en la nube sin servidor y de bajo costo para un uso muy intermitente). Otro caso de uso adecuado sería evitar olvidarse de desactivar una instancia de desarrollo en la nube una vez terminada; es valioso "pausar automáticamente" una base de datos que no es de producción (aunque eso requiere una funcionalidad mucho más simple que la imaginada sin servidor).

¿Pero para su base de datos de producción y en entornos más operativos? No querrás escalar a cero.

Escalar a cero significa un “arranque en frío” al reiniciar: buffers compartidos de base de datos vacíos, caché del sistema operativo vacío, cachés de catálogo vacíos (en el caso de PostgreSQL).

(Sí, algunas bases de datos sin servidor reducen el tiempo necesario para iniciar la ejecución de la base de datos, pero lo hacen desde un estado vacío. En una base de datos relacional como PostgreSQL, puede llevar minutos (¡o más!) volver a crear un conjunto de trabajo cálido. especialmente para bases de datos más grandes).

El impacto en el rendimiento del arranque en frío es aún mayor ya que muchas bases de datos sin servidor adoptan diferentes arquitecturas de almacenamiento en la nube, donde el costo y la latencia de recuperar páginas de bases de datos desde el almacenamiento remoto a la memoria son aún mayores. Estos gastos generales nuevamente conducen a un peor rendimiento o obligan a los proveedores de plataformas a compensar utilizando mayores recursos físicos (por ejemplo, las bases de datos de Amazon Aurora tienen el doble de memoria que RDS), un costo que finalmente se traslada a los usuarios.

Entonces, en muchos escenarios, las bases de datos sin servidor terminan con precios más altos e impredecibles.

Por ejemplo, si compara Aurora Serverless con Amazon RDS, verá que el procesamiento de 8 vCPU y 500 GB de almacenamiento en Serverless es un 85 % más caro que RDS ($1097 frente a $593). Y esto es gracias a Aurora I/O Optimized y sus precios de almacenamiento más predecibles, que se lanzaron hace apenas seis meses. (Aunque, incluso aquí, todavía tenemos que inferir su capacidad informática real, ya que los precios de Aurora Serverless confunden las opacas "Unidades de capacidad Aurora", que según nuestras estimaciones mejor informadas son 1 ACU = 0,25 vCPU).

Anteriormente, con Aurora Standard, los usuarios también pagaban por cada operación de E/S interna, lo que era casi imposible de predecir o presupuestar. Muchas bases de datos sin servidor siguen cobrando por dichas lecturas y escrituras. De hecho, cuando comparamos AWS Timestream sin servidor, vimos costos que terminaron siendo más de 100 veces más altos que con Timescale debido a todos estos costos marginales más altos. La imprevisibilidad y variabilidad de los costos eran lo opuesto a estar libre de preocupaciones.

En resumen, las bases de datos sin servidor son propensas a tener un rendimiento deficiente, facturas impredecibles y costos elevados a medida que aumentan las cargas de trabajo. Sólo son adecuados para cargas de trabajo intermitentes que se activan sólo ocasionalmente y pueden tolerar arranques en frío debido a su falta de almacenamiento en caché de datos en memoria.

El dilema del desarrollador

Aquí es donde hemos terminado:

• Muchos desarrolladores todavía eligen los servicios DBaaS tradicionales con aprovisionamiento para aplicaciones de producción debido a su rendimiento confiable, control y comprensibilidad, pero odian el desperdicio que surge de la necesidad de un aprovisionamiento excesivo.

  
  

• Algunos desarrolladores eligen bases de datos sin servidor por su aparente ahorro de costos, flexibilidad y facilidad de uso, pero odian el impacto en el rendimiento y los precios impredecibles y oscuros (que a menudo resultan en facturas misteriosamente más altas que las de una instancia aprovisionada).

  
  

Como desarrolladores, ¡ninguna de estas opciones es muy atractiva! Hay una oportunidad para mejorar.

Solución: Presentación de PostgreSQL dinámico

Por eso desarrollamos Dynamic PostgreSQL.

Dynamic PostgreSQL respalda consistentemente su línea de base y escala sin problemas la computación cuando la necesita, hasta un máximo definido. Esto lo hace perfecto para la variedad de cargas de trabajo continuas que normalmente se ven en entornos de producción (ya sean uniformes, variables o en ráfagas).

Dynamic PostgreSQL es 100 % PostgreSQL, con todos los beneficios de la comunidad y el ecosistema PostgreSQL, más el madurez de la plataforma de base de datos de Timescale . Para construir Dynamic PostgreSQL, hemos innovado en cómo operamos nuestra infraestructura de PostgreSQL en lugar de modificar las partes internas de PostgreSQL. Esto le brinda acceso a todo lo que ofrece PostgreSQL (y la plataforma Timescale), sin temor a ejecutar una consulta PostgreSQL bifurcada o un motor de almacenamiento.

Con Dynamic PostgreSQL, usted elige un rango de computación (una CPU mínima y máxima) correspondiente a sus necesidades de carga de trabajo. Este rango de computación también viene con una memoria efectiva que es equivalente a lo que la mayoría de los servicios DBaaS ofrecen tradicionalmente en el extremo "máximo" del rango de computación.

La base (mínima) de su rango de CPU actúa exactamente como el modelo DBaaS aprovisionado: la CPU mínima está dedicada en todo momento a su servicio para ejecutar su aplicación. A medida que aumenta su carga, ya sea debido a la demanda de su aplicación externa o incluso debido a tareas internas ocasionales de la base de datos, como copias de seguridad incrementales o limpieza automática de tablas, su base de datos puede utilizar hasta el pico (máximo) de su rango de CPU sin demora.

¿Cómo logramos un retraso cero? La computación dinámica funciona de manera diferente a otras ofertas de bases de datos sin servidor o de escalamiento automático, por lo que no implica el escalamiento lento (y el impacto en el rendimiento) que normalmente se observa en las migraciones remotas. En cambio, nuestros algoritmos de configuración de infraestructura y ubicación de cargas de trabajo garantizan que las bases de datos puedan ampliarse en su nodo subyacente sin reinicios ni reconfiguraciones. Su instancia siempre tiene acceso a su cálculo máximo según sea necesario.

Y lo mejor es que sólo pagas por la base más lo que uses encima. A este modelo de elección de un rango de cómputo y escalamiento entre él lo llamamos " comprar la base, alquilar el pico ".

Por ejemplo, si elige una opción de 4 a 8 CPU, siempre tendrá 4 CPU dedicadas a su servicio y 32 GB de memoria efectiva. Esto asegura un buen rendimiento de la base en todo momento. Cuando su carga aumenta, su aplicación puede usar hasta 8 CPU instantáneamente según sea necesario (medidas y facturadas en base a una CPU fraccionaria) y nunca más de 8 CPU si este es su límite máximo.

El modelo dinámico le permite “dimensionar” su base de datos de manera más rentable y sin preocupaciones. Puede elegir un rango de cálculo en el que su demanda estándar se ajuste al mínimo, pero puede aumentar o aumentar hasta el pico (máximo) según sea necesario. Este máximo crea un límite inherente a cualquier uso superior a su cálculo base, lo que genera un límite de costos fácil de entender. Además, cobramos la misma tarifa por hora de CPU (fracción) tanto para su base como para cualquier uso medido superior a esto: no hay ningún recargo por usar por encima de su base y, por lo tanto, no hay penalización de precio por escalar.

Finalmente, si se da cuenta de que aprovisionó un rango de tamaño demasiado bajo o demasiado alto, puede ajustar fácilmente su rango de cálculo a un tamaño que se adapte mejor a las necesidades de su aplicación.

Diseñado para ahorrarle dinero

Actualmente ofrecemos cinco rangos de computación diferentes según el tamaño de su carga de trabajo, con la memoria efectiva correspondiente que recibe para el rango independientemente de su uso instantáneo.

Dynamic PostgreSQL también utiliza el almacenamiento basado en el uso de Timescale, donde solo paga por el volumen de datos almacenados (en GB-hora), no por el tamaño del disco aprovisionado. No te preocupes por desperdiciar dinero con un disco sobreaprovisionado ni por quedarte sin espacio en el disco. La infraestructura dinámica de nube de Timescale garantiza que tenga suficiente capacidad de almacenamiento, cuando la necesite, y que solo pague por lo que use.

Hemos desarrollado Dynamic PostgreSQL intencionalmente para ahorrarle dinero. Los clientes que ejecutan cargas de trabajo de producción normalmente ahorran entre un 10 y un 20 % al migrar desde AWS RDS para PostgreSQL y entre un 50 y un 70 % cuando migran desde AWS Aurora Serverless.

Al final del mes, su factura consta de dos métricas simples y fáciles de entender: (1) sus costos de computación, facturados como su computación base por hora más cualquier uso fraccional de CPU por encima de este, pero no más que su pico; y (2) sus costos de almacenamiento, facturados como consumo de datos en GB-hora. No hay nuevas métricas ni unidades derivadas para medir o comprender.

Sólo paga por lo que usas. Cero costes extra o tarifas ocultas.

• Computación: predecible, basada en un rango definido

• Almacenamiento: paga solo por lo que almacenas

  
  

Sin desperdiciar recursos. Sin pagar de más. No perder el sueño por la noche. Una factura que puedes explicarle a tu jefe.

Pruébalo hoy

¡Puedes probar Dynamic PostgreSQL hoy! Timescale ofrece una prueba gratuita —no se requiere tarjeta de crédito—que le brinda acceso completo a la plataforma durante 30 días. Para crear un servicio PostgreSQL dinámico, simplemente seleccione la opción PostgreSQL al iniciar sesión en Timescale:

La plataforma ahora ofrece dos tipos de servicios para satisfacer las necesidades específicas de sus bases de datos:

• Los servicios de series temporales están diseñados para aumentar la velocidad de consulta y la escalabilidad para sus cargas de trabajo más exigentes, ofreciendo características clave de Timescale como hipertablas, compresión en columnas, agregados continuos y almacenamiento por niveles. Úselos para alojar los datos de sus sensores, métricas de energía, datos financieros, eventos y otras cargas de trabajo con uso intensivo de datos.

  
  

• Los servicios PostgreSQL son servicios dinámicos de Postgres optimizados para ofrecer rentabilidad y facilidad de uso. Utilícelos para sus bases de datos sólo relacionales, por ejemplo, registros comerciales.

  
  

Una vez que seleccione "PostgreSQL", configurar su servicio Dynamic PostgreSQL es súper simple. Seleccione su región, su rango de computación dinámica y sus opciones de alta disponibilidad y agrupación de conexiones: ¡boom! 💥 Ahora tiene una base de datos dinámica de PostgreSQL lista para usar en producción.

Si tienes alguna pregunta, contactanos . ¡Nos encantaría escuchar sus comentarios y ayudarlo con su caso de uso de PostgreSQL (serie temporal o no)!

Este es solo el comienzo. Estamos en medio de tres semanas de lanzamiento consecutivas y esto es solo el comienzo de la Semana 2: Semana de infraestructura dinámica. Estén atentos para más información esta semana, este mes, este año y los años venideros. 🙂

- Escrito por Mike Freedman y Grant Godeke.