:Serverless mode

Descripción general

En el modo Serverless, AnalyticDB for PostgreSQL desacopla los recursos de cómputo y almacenamiento para permitir su escalado en proporciones independientes. Los recursos de almacenamiento se facturan bajo el modelo pay-as-you-go, mientras que la capacidad de cómputo se escala de forma independiente según las necesidades del negocio. Esto reduce los costos de almacenamiento y mejora la eficiencia operativa.

AnalyticDB for PostgreSQL en modo Serverless presenta las siguientes ventajas frente al modo de almacenamiento elástico:

• Reduce los costos de almacenamiento y permite el uso de recursos bajo demanda. Con AnalyticDB for PostgreSQL en modo Serverless, puede implementar análisis de datos rentables sin necesidad de migrar sus datos a otros medios de almacenamiento. Este modo satisface los requisitos de análisis de datos de los sectores financiero y de Internet.

• Optimiza escrituras de alto throughput y operaciones de procesamiento por lotes de alto rendimiento mediante escalado elástico, lo cual resulta ideal para escenarios con grandes volúmenes de datos y fluctuaciones significativas de tráfico.

• Ofrece la función de uso compartido de datos basada en la separación de recursos de almacenamiento y cómputo. Los datos compartidos son accesibles desde otras bases de datos sin necesidad de exportarlos ni importarlos. Esta alternativa es más sencilla y económica que el acceso a datos en almacenes de datos tradicionales.

Notas de uso

Comparación de modos de servicio

El modo Serverless admite la mayoría de las funciones del modo de almacenamiento elástico. La siguiente tabla describe las diferencias entre ambos modos de servicio.

Límites

El modo Serverless admite más del 95 % de las funciones disponibles en el modo de almacenamiento elástico. En la mayoría de los casos, se utiliza la misma sintaxis para ambos modos. Herramientas como el conector Java Database Connectivity (JDBC), el conector Open Database Connectivity (ODBC) y psql funcionan en el modo Serverless de la misma manera que en el modo de almacenamiento elástico. La siguiente tabla describe los límites de AnalyticDB for PostgreSQL en modo Serverless respecto a ciertas funciones específicas.

Migración de datos

Puede migrar datos desde una instancia de AnalyticDB for PostgreSQL en modo de almacenamiento elástico o reservado hacia una instancia en modo Serverless. Para obtener más información, consulte Migrate data between AnalyticDB for PostgreSQL instances.

La siguiente tabla describe la compatibilidad del modo Serverless con los distintos tipos de migración de datos.

Programación automática (en vista previa por invitación)

Las instancias de AnalyticDB for PostgreSQL en modo de programación automática Serverless pueden pausarse y reanudarse automáticamente según la detección de tráfico. Si no hay tráfico, las instancias pasan automáticamente al estado inactivo. No se cobran recursos de cómputo mientras las instancias permanecen en este estado.

En las instancias de AnalyticDB for PostgreSQL con programación automática Serverless, puede modificar los valores de los parámetros Computing Resource Threshold y Wait Time for Idle Resource Release. Para obtener más información, consulte Instance resource configuration.

La facturación de las instancias en modo de programación automática Serverless se realiza por segundo, con base en las unidades de cómputo de AnalyticDB (ACU) que miden la potencia de cómputo de las instancias. El sistema recopila la cantidad de ACU utilizadas y genera facturas cada hora. Para obtener más información, consulte Pricing.

Escalado elástico

Las instancias en modo Serverless pueden escalarse en cuestión de minutos. A continuación se proporciona un rendimiento de escalado de referencia:

• Una instancia con 16 nodos de cómputo o menos puede escalarse en menos de 60 segundos.

• Una instancia con más de 16 nodos de cómputo puede escalarse en menos de 5 minutos.

Utilice la capacidad de escalado elástico de AnalyticDB for PostgreSQL en modo Serverless para aumentar los nodos de cómputo antes de períodos pico previstos, como el Double 11, y reducirlos después de esas horas punta. AnalyticDB for PostgreSQL se factura por hora según la duración real del uso de recursos y las especificaciones de los nodos de cómputo. De esta forma, minimiza los costos sin comprometer el rendimiento del servicio.

En el modo Serverless, cada nodo de cómputo tiene una capacidad máxima de almacenamiento. Antes de reducir los nodos de cómputo, asegúrese de que el volumen total de datos no exceda la capacidad máxima combinada de todos los nodos restantes. Por ejemplo, si cada nodo de cómputo ofrece 2 núcleos, 8 GB de memoria y una capacidad máxima de almacenamiento de 960 GB, y desea reducir su instancia a cuatro nodos, el volumen total de datos no debe superar los 3,840 GB (960 GB × 4).

La siguiente tabla describe la capacidad máxima de almacenamiento para las distintas especificaciones de nodos de cómputo en AnalyticDB for PostgreSQL en modo Serverless.

Salvo durante las interrupciones breves que ocurren antes y después del escalado, las cargas de trabajo mantienen la capacidad de lectura y escritura durante todo el proceso.

Uso compartido de datos (beta)

En comparación con los métodos tradicionales de importación y exportación de datos en almacenes de datos, el uso compartido de datos en AnalyticDB for PostgreSQL en modo Serverless ofrece las siguientes ventajas:

• Reducción de costos de almacenamiento: No es necesario replicar ni migrar datos entre instancias de AnalyticDB for PostgreSQL. Se almacena una sola copia de los datos en el almacenamiento distribuido, la cual puede ser compartida por varias instancias dentro del rango especificado. Esto reduce significativamente el espacio de almacenamiento requerido.

• Facilidad de uso: Una vez que crea un recurso compartido en una instancia productora, configura la autorización e importa los datos al recurso compartido, puede acceder a ellos desde una instancia consumidora de la misma forma que accede a los datos en la instancia productora. No es necesario migrar el esquema de la tabla. La adición o eliminación de objetos compartidos y los cambios de autorización se sincronizan automáticamente con la instancia consumidora.

• Consistencia de datos: Las instancias consumidoras pueden acceder a los datos compartidos con capacidades muy similares a las de las instancias productoras. Además, las instancias consumidoras pueden leer los últimos datos escritos por las instancias productoras, lo que garantiza las propiedades de atomicidad, consistencia, aislamiento y durabilidad (ACID) de las transacciones.

El uso compartido de datos le ayuda a resolver los siguientes problemas:

• Aislamiento entre permisos organizacionales complejos: Por ejemplo, si existe una instancia en la sede corporativa y otra en una sucursal, el uso compartido de datos permite que la instancia de la sucursal acceda a datos específicos de la instancia central.

• Aislamiento entre recursos empresariales complejos: Por ejemplo, cuando los recursos físicos están aislados entre procesos ETL (extracción, transformación y carga) y consultas ad hoc, el uso compartido de datos facilita la distribución de resultados ETL entre las instancias que ejecutan consultas ad hoc.

• Fallas en la colaboración interdepartamental: Por ejemplo, si un mismo conjunto de datos debe ser analizado por equipos de I+D, ventas, operaciones y finanzas, el uso compartido de datos permite el acceso controlado por diferentes grupos empresariales dentro de la organización.

El uso compartido de datos se encuentra en fase beta y presenta los siguientes límites:

• Se admite en tablas estándar, pero no en tablas particionadas, tablas externas, vistas, esquemas ni funciones.

• Es compatible con tablas distribuidas por hash, pero no con tablas replicadas ni tablas aleatorias.

• No se admite en subtransacciones.

• Si una instancia productora contiene varios recursos compartidos, una instancia consumidora solo puede suscribirse a uno de ellos.

• No se permiten operaciones DDL en tablas compartidas. Para ejecutar operaciones DDL en una tabla compartida, primero debe deshabilitar el uso compartido para dicha tabla.

Referencias

• [[Notice] Serverless mode released for AnalyticDB for PostgreSQL](t2130215.dita#concept_2130215)

• Quick start for elastic storage mode

• Migrate data between AnalyticDB for PostgreSQL instances

• Performance test for data import and query in Serverless Pro mode

• 数据共享