Preguntas frecuentes sobre Amazon Timestream

Los datos de serie temporal son una secuencia de puntos de datos (como los precios de stock, la temperatura y el uso de la CPU de una instancia de Amazon EC2) registrados a lo largo del tiempo. Con los datos de serie temporal, cada punto de datos consta de una marca de tiempo, uno o más atributos y el evento que cambia con el tiempo. Estos datos se utilizan para obtener información sobre el rendimiento y el estado de una aplicación, detectar anomalías e identificar oportunidades de optimización.

Por ejemplo, los ingenieros de DevOps podrían querer ver los datos que miden los cambios en las métricas de rendimiento de la infraestructura; los fabricantes podrían querer rastrear los datos de los sensores de IoT que miden los cambios de temperatura en los equipos de una instalación; y los vendedores en línea podrían querer analizar los datos de secuencias de clics que capturan la forma en que un usuario navega por un sitio web a lo largo del tiempo. Dado que los datos de serie temporal se generan a partir de múltiples orígenes en volúmenes extremadamente altos, es necesario almacenarlos y analizarlos de manera rentable casi en tiempo real para obtener información empresarial clave.

Amazon Timestream ofrece InfluxDB totalmente administrado, una de las bases de datos de serie temporal de código abierto más populares del mercado, y LiveAnalytics, una base de datos de serie temporal sin servidor creada para escalar.

Sí. Puede comprar un Savings Plans para bases de datos para el uso de Amazon Timestream y reducir los costos hasta un 20 % cuando se compromete con una cantidad constante de uso durante un periodo de un año. Puede encontrar información adicional sobre el uso elegible en la página de precios de Savings Plans para bases de datos.

Puede empezar a trabajar con Timestream mediante el uso de la consola de administración de AWS, la interfaz de la línea de comandos de AWS (AWS CLI) o los SDK. Para obtener más información, incluidos los tutoriales y otro contenido de introducción, consulte la guía para desarrolladores.

Amazon Timestream para InfluxDB debe usarse en casos de uso que requieran consultas de serie temporal casi en tiempo real y cuando necesite características de InfluxDB o API de código abierto. El motor de Timestream existente, Amazon Timestream para LiveAnalytics, debe usarse cuando necesite ingerir más de decenas de gigabytes de datos de serie temporal por minuto y ejecutar consultas SQL en terabytes de datos de serie temporal en segundos.

Sí. Los dos motores se complementan entre sí para una ingesta de datos de serie temporal a gran escala y de baja latencia. Puede ingerir datos en Timestream para InfluxDB y usar un complemento de Telegraf para enviar datos a Timestream para analizar datos históricos a través de consultas SQL.

Si decide migrar sus datos de Timestream para InfluxDB a Timestream para LiveAnalytics, incurrirá en cargos de facturación pública por el uso de ese servicio, incluidos la ingestión, el almacenamiento y las consultas. Es opcional usar Timestream para LiveAnalytics con Timestream para InfluxDB.

Timestream para InfluxDB se puede usar por separado o con su Timestream para las cargas de trabajo de LiveAnalytics. Timestream para InfluxDB está dirigido a aplicaciones casi en tiempo real con tiempos de respuesta de milisegundos de un solo dígito. Timestream para LiveAnalytics aborda casos de uso en los que es necesario ingerir gigabytes de datos en minutos y consultar terabytes de datos en segundos. Puede combinar Timestream para InfluxDB y Timestream para LiveAnalytics en sus aplicaciones o paneles.

No. Timestream crea de forma dinámica un esquema de tabla en función de un conjunto de atributos y medidas dimensionales. Esto ofrece una definición de esquema flexible e incremental que se puede ajustar en cualquier momento sin afectar a la disponibilidad.

Una vez que las bases de datos se hayan creado y estén disponibles, puede recuperar la información de los puntos de conexión desde la consola de Timestream. Como alternativa, también puede usar la API Describe para recuperar información de punto de conexión (DescribeDatabase cuando usa Timestream para LiveAnalytics y DescribeDBInstances cuando usa Timestream para InfluxDB).

Puede visualizar los datos de serie temporal de Timestream y crear alertas con Grafana, una herramienta multiplataforma de análisis de código abierto y visualización interactiva. Para obtener más información y encontrar ejemplos de aplicaciones, consulte la documentación.

Puede crear funciones de AWS Lambda que interactúen con Timestream. Para obtener información más detallada, consulte la documentación.

Puede enviar los datos de serie temporal recopilados con Telegraf de código abierto directamente a Timestream mediante el conector de Telegraf. Para obtener información más detallada, consulte la documentación.

Ahora puede obtener acceso a Timestream desde su Amazon Virtual Private Cloud (Amazon VPC) mediante los puntos de conexión de VPC. Los puntos de conexión de Amazon VPC son muy fáciles de configurar y proporcionan una conectividad de confianza a las API de Timestream sin necesidad de una puerta de enlace de Internet o una instancia de NAT.

AWS CloudFormation simplifica el aprovisionamiento y la administración al proporcionar plantillas de CloudFormation para un aprovisionamiento rápido y de confianza de los servicios o las aplicaciones. CloudFormation ofrece un soporte integral para Timestream al proporcionar plantillas para crear bases de datos (tanto para Timestream para LiveAnalytics como para Timestream para InfluxDB). Las plantillas están actualizadas con el último anuncio de Timestream para InfluxDB y brindan flexibilidad y facilidad de uso a los clientes de Timestream.

Amazon Timestream para LiveAnalytics es una base de datos de serie temporal rápida, escalable y sin servidor creada para cargas de trabajo a gran escala. No tiene servidores y se escala o desescala verticalmente de manera automática para ajustar la capacidad y el rendimiento, por lo que no es necesario administrar la infraestructura subyacente. Su arquitectura totalmente desacoplada le permite ingerir billones de puntos de datos y ejecutar millones de consultas al día.

El motor de consultas adaptativo de Timestream para LiveAnalytics le permite acceder a los datos recientes e históricos y analizarlos de forma conjunta, sin tener que especificar la ubicación. Tiene funciones de análisis de serie temporal integradas, lo que lo ayuda a identificar tendencias y patrones en los datos casi en tiempo real.

Timestream para LiveAnalytics está diseñado para recopilar, almacenar y procesar datos de serie temporal. Su arquitectura sin servidor admite servicios de procesamiento de consultas, almacenamiento e ingesta de datos totalmente desacoplados que pueden escalarse de forma independiente, lo que permite una escala prácticamente infinita para satisfacer las necesidades de su aplicación. En lugar de predefinir el esquema en el momento de la creación de la tabla, un esquema de tabla de Timestream se crea de forma dinámica en función de los atributos de los datos de serie temporal entrantes, lo que permite una definición del esquema flexible e incremental.

Para el almacenamiento de datos, Timestream para LiveAnalytics divide los datos por tiempo y atributos, lo que acelera el acceso a los datos mediante un índice creado específicamente. Los atributos de los datos, como el nombre de la medida o la clave de partición elegida, desempeñan un papel fundamental a la hora de particionar y recuperar los datos de forma eficaz. Además, Timestream para LiveAnalytics automatiza la administración del ciclo de vida de los datos al ofrecer un almacenamiento en memoria para los datos recientes y un almacén magnético para los datos históricos, así como al admitir reglas configurables para mover de forma automática los datos del almacén de memoria al almacenamiento magnético cuando alcanzan una determinada antigüedad.

Timestream para LiveAnalytics también simplifica el acceso a los datos a través del motor de consultas adaptativas especialmente diseñado que puede acceder a los datos y combinarlos sin problemas en todos los niveles de almacenamiento sin tener que especificar la ubicación de los datos, de modo que usted pueda obtener información de sus datos, de manera rápida y fácil, mediante SQL. Por último, Timestream funciona a la perfección con sus servicios preferidos de recopilación de datos, visualización, análisis y machine learning (ML), lo que le facilita la inclusión de Timestream en las soluciones de serie temporal.

Timestream para LiveAnalytics ofrece una disponibilidad de hasta el 99,99 %. Para obtener más información, consulte el acuerdo de nivel de servicio (SLA).

Con Timestream para LiveAnalytics, solo paga por lo que usa. Las escrituras, los datos almacenados y los datos analizados por las consultas se facturan por separado. Timestream automáticamente escala sus escrituras, almacenamiento y capacidad de consulta con base en el uso. Puede establecer una política de retención de datos para cada tabla y elegir dónde se almacenarán los datos: si lo hacen en memoria o en un almacenamiento magnético. Para ver los precios detallados, consulte la página de precios.

Sí, Timestream para LiveAnalytics ofrece una prueba gratuita de 1 mes para todas las cuentas nuevas. El uso de la prueba gratuita tiene un límite de 50 GB de ingesta, 100 GB de almacenamiento magnético, 750 GB de horas de almacenamiento de memoria y 750 GB de datos analizados.

Se le facturará según los precios estándar de Timestream para LiveAnalytics por el uso que supere lo que ofrece la prueba gratuita. Encontrará más información en la página de precios.

Para conocer la disponibilidad regional actual, consulte la página de precios.

Timestream para LiveAnalytics ofrece latencias casi en tiempo real para la ingesta de datos. El almacén de memoria integrado de Timestream para LiveAnalytics está optimizado para consultas rápidas puntuales; y el almacenamiento magnético está optimizado para admitir consultas analíticas rápidas. Con Timestream para LiveAnalytics, puede ejecutar consultas que analicen decenas de gigabytes de datos de serie temporal del almacén de memoria en cuestión de milisegundos, y consultas analíticas que analicen terabytes de datos de serie temporal del almacenamiento magnético en cuestión de segundos. Las consultas programadas mejoran aún más el rendimiento de las consultas, ya que se calculan y almacenan los agregados, los resúmenes y otros análisis en tiempo real que se utilizan para impulsar los paneles operativos, los informes empresariales, las aplicaciones y los sistemas de supervisión de dispositivos a los que se accede con frecuencia.

Puede almacenar exabytes de datos en una sola tabla. A medida que los datos crecen, Timestream para LiveAnalytics usa su arquitectura distribuida y enormes cantidades de paralelismo para procesar volúmenes de datos mayores y, al mismo tiempo, mantener las latencias de consulta prácticamente sin cambios.

La arquitectura sin servidor de Timestream admite sistemas de procesamiento de consultas, almacenamiento e ingesta de datos totalmente desacoplados que pueden escalar de forma independiente. Timestream para LiveAnalytics supervisa continuamente los requisitos de su aplicación en cuanto a la ingesta, el almacenamiento y la tasa de consultas para escalar instantáneamente sin ningún tiempo de inactividad para la aplicación.

Para conocer los límites y las cuotas actuales, consulte la documentación.

Puede recopilar datos de serie temporal de dispositivos conectados, sistemas de TI y equipos industriales, y escribirlos en Timestream para LiveAnalytics. Puede enviar datos a Timestream para LiveAnalytics directamente desde su aplicación mediante los SDK de AWS o desde servicios de recopilación de datos como AWS IoT Core, Amazon Managed Service para Apache Flink o Telegraf. Para obtener más información, consulte la documentación.

Los datos de llegada tardía son datos que tienen una marca de tiempo del pasado y están fuera del límite de retención del almacén de memoria. Los datos futuros son los que tienen una marca de tiempo en el futuro. Timestream le permite almacenar y acceder a ambos tipos de datos.

Para almacenar los datos que llegan tarde, solo debe escribirlos en Timestream para LiveAnalytics, y el servicio determinará de forma automática si se escriben en el almacén de memoria o en el almacén magnético, según la marca de tiempo de los datos y del periodo de retención de datos configurado para los almacenes magnéticos y de memoria. Para almacenar datos con una antelación de más de 15 minutos, modele los datos como un registro de medidas múltiples y represente la marca de tiempo futura como una medida dentro del registro.

Mediante la carga por lotes, puede incorporar archivos CSV almacenados en Amazon Simple Storage Service (Amazon S3) a Timestream para LiveAnalytics. Puede utilizar la carga por lotes para rellenar datos que no sean necesarios de inmediato para el análisis. Puede crear tareas de carga por lotes mediante la consola de administración de AWS, la AWS CLI y los SDK de AWS. Para obtener más información, consulte la documentación.

Puede recopilar datos de los dispositivos de IoT y almacenarlos en Timestream para LiveAnalytics mediante las acciones de reglas de AWS IoT Core. Para obtener información más detallada, consulte la documentación.

Puede usar Apache Flink para transferir los datos de serie temporal de Amazon Kinesis directamente a Timestream para LiveAnalytics. Para obtener información más detallada, consulte la documentación.

Puede usar Apache Flink para enviar sus datos de serie temporal desde Amazon Managed Streaming para Apache Kafka (Amazon MSK) directamente a Timestream para LiveAnalytics. Para obtener información más detallada, consulte la documentación.

Timestream organiza y almacena datos de serie temporal en particiones. El servicio determina la partición de los datos en función de los atributos de los datos. Los atributos como timestamp y measure_name o las claves de partición definidas por el cliente desempeñan un papel clave a la hora de decidir las particiones. Consulte el blog de Werner Vogels para obtener más detalles. Si quiere optimizar el rendimiento de las consultas para que se ajusten mejor a sus necesidades específicas, le recomendamos usar claves de partición definidas por el cliente. Con Timestream, puede automatizar la administración del ciclo de vida de los datos; para ello, solo debe configurar las políticas de retención de datos para mover automáticamente los datos del almacén de memoria al almacenamiento magnético a medida que alcancen la antigüedad configurada.

El almacén de memoria de Timestream para LiveAnalytics es un almacén optimizado para escritura que acepta y deduplica los datos de serie temporal entrantes. El almacén de memoria también está optimizado para consultas a un momento dado y sensibles a la latencia.

El almacenamiento magnético de Timestream para LiveAnalytics es un almacenamiento optimizado para la lectura creado para ejecutar consultas analíticas rápidas que pueden analizar cientos de terabytes de datos. El almacenamiento magnético también está optimizado para consultas analíticas rápidas que analizan cientos de terabytes de datos.

Puede establecer el periodo de retención tanto para el almacenamiento de memoria como para el almacenamiento magnético. Los valores predeterminados son 12 horas y 10 años, respectivamente. A medida que la antigüedad de los datos, determinada por la marca de tiempo del registro, supera el periodo de retención configurado del almacén de memoria, Timestream para LiveAnalytics clasifica automáticamente los datos en niveles en el almacenamiento magnético. Del mismo modo, si la antigüedad de los datos supera el periodo de retención del almacenamiento magnético configurado, el servicio elimina automáticamente los datos.

Timestream para LiveAnalytics garantiza la durabilidad de sus datos al replicar automáticamente los datos de su almacenamiento magnético y de memoria en diferentes zonas de disponibilidad dentro de una sola región. Todos los datos se escriben en el disco antes de confirmar que la solicitud de escritura se ha completado.

Puede usar SQL para consultar los datos de serie temporal almacenados en Timestream. También puede usar funciones de análisis de datos de serie temporal para la interpolación, la regresión y el suavizado mediante SQL. Para obtener más información, consulte la documentación. El motor de consultas adaptativo de Timestream le permite acceder a los datos en todos los niveles de almacenamiento mediante una sola instrucción SQL. Accede a los datos de todos los niveles de almacenamiento y los combina de forma transparente sin necesidad de especificar la ubicación de los datos. 

Las consultas programadas de Timestream para LiveAnalytics ofrecen una solución escalable, sin servidores y completamente administrada para calcular y almacenar agregados, acumulaciones y otros análisis en tiempo real que se utilizan para impulsar los paneles operativos, los informes empresariales, las aplicaciones y los sistemas de monitorización de dispositivos a los que se accede con frecuencia.

Con las consultas programadas, solo tiene que definir las consultas de análisis en tiempo real que calculan agregados, acumulaciones y otros análisis en tiempo real de los datos entrantes. Luego, Timestream ejecuta estas consultas de forma periódica y automática, y escribe los resultados de la consulta de forma fiable en una tabla independiente. A partir de esto, puede dirigir sus paneles, informes, aplicaciones y sistemas de supervisión para que consulten simplemente las tablas de destino en lugar de consultar las tablas de origen, considerablemente más grandes, que contienen los datos de serie temporal entrantes. De esta forma, se reducen el rendimiento y los costos en un orden de magnitud, ya que las tablas de destino contienen muchos menos datos que las tablas de origen, lo que ofrece un acceso y un almacenamiento de datos más rápidos y económicos.

Puede usar los controladores JDBC y ODBC para conectar Timestream para LiveAnalytics a sus herramientas de inteligencia empresarial y otras aplicaciones preferidas. Consulte la documentación de JDBC y ODBC para obtener más información.

Puede visualizar y analizar datos de serie temporal en Timestream para LiveAnalytics con Amazon QuickSight y Grafana. También puede usar QuickSight para sus necesidades de ML.

Puede crear paneles completos e interactivos para sus datos de serie temporal con QuickSight. Para obtener más información, consulte la documentación.

Puede usar los cuadernos de Amazon SageMaker para integrar los modelos de ML con Timestream para LiveAnalytics. Para obtener más información, consulte la documentación.

Los datos siempre están cifrados, ya sea en reposo o en tránsito. Timestream para LiveAnalytics le permite especificar una clave de AWS Key Management Service (AWS KMS) administrada por el cliente para cifrar los datos del almacén magnético.

Timestream para LiveAnalytics cumple con las normas ISO (9001, 27001, 27017 y 27018), PCI DSS, FedRAMP (moderado) y Health Information Trust (HITRUST) Alliance Common Security Framework (CSF). También cumple con los requisitos de la HIPAA y está dentro del ámbito de los informes SOC 1, SOC 2 y SOC 3 de AWS.

Tiene dos opciones de copia de seguridad disponibles para los recursos de Timestream: bajo demanda y programadas. Las copias de seguridad bajo demanda son copias de seguridad puntuales que se pueden iniciar desde la consola de Timestream o AWS Backup. Las copias de seguridad bajo demanda son útiles cuando se desea crear una copia de seguridad antes de realizar un cambio en la tabla que puede requerir que se reviertan los cambios. Las copias de seguridad programadas son copias de seguridad periódicas que usted puede configurar mediante las políticas de AWS Backup con la frecuencia deseada (por ejemplo, 12 horas, 1 día, 1 semana, etc.). Las copias de seguridad programadas son útiles cuando se desea crear copias de seguridad continuas para cumplir con los objetivos de protección de datos.

La primera copia de seguridad de la tabla, ya sea bajo demanda o programada, es una copia de seguridad completa, y todas las copias de seguridad posteriores de la misma tabla son incrementales y solo copian los datos que han cambiado desde la última copia de seguridad. 

Las copias de seguridad y las restauraciones se cobran en función del tamaño del almacenamiento de copias de seguridad de la tabla seleccionada, medido en GB por mes. Los cargos se mostrarán en la sección Copia de seguridad en la factura de AWS e incluirán los costos del almacenamiento de copias de seguridad, las transferencias de datos, las restauraciones y las eliminaciones anticipadas. Las copias de seguridad son de naturaleza incremental; por lo tanto, el tamaño de almacenamiento de la copia de seguridad posterior de la tabla es el tamaño de la cantidad de datos que se modificaron desde la última copia de seguridad. Consulte los precios de AWS Backup para obtener más información.

Para empezar, debe habilitar AWS Backup para proteger los recursos de Timestream para LiveAnalytics (esta acción se realiza una sola vez). Luego de habilitarla, vaya a la Consola de administración de AWS o use la CLI o el SDK de AWS Backup para crear copias de seguridad programadas o bajo demanda de sus datos, y copie esas copias de seguridad en las cuentas y regiones. Puede configurar la administración del ciclo de vida de las copias de seguridad en función de las necesidades de protección de datos. Para obtener más información, consulte la documentación sobre la creación de una copia de seguridad. 

Puede restaurar las tablas de Timestream para LiveAnalytics a través de la consola de administración de AWS o mediante la CLI o el SDK de AWS Backup. Seleccione el ID del punto de recuperación del recurso que desea restaurar y proporcione las entradas necesarias, como el nombre de la base de datos de destino, el nombre de la tabla nueva y las propiedades de retención, para iniciar el proceso de restauración. Luego de la correcta restauración, puede acceder a los datos. Cuando intenta restaurar la última copia de seguridad incremental de la tabla, se restauran todos los datos de la tabla. Para obtener más información, consulte la documentación.

Amazon Timestream para InfluxDB es un nuevo motor de bases de datos de serie temporal que facilita a los desarrolladores de aplicaciones y a los equipos de DevOps la ejecución de bases de datos de InfluxDB en AWS para aplicaciones de serie temporal en tiempo real mediante API de código abierto. Con Timestream para InfluxDB, es fácil configurar, operar y escalar cargas de trabajo de serie temporal que pueden responder consultas con respuestas de un solo dígito en milisegundos.

Timestream para InfluxDB es compatible con la versión 2.7 de código abierto de InfluxDB. 

Debe usar Timestream para InfluxDB si está autoadministrando InfluxDB, quiere usar API de serie temporal de código abierto o está creando aplicaciones de serie temporal en tiempo real que requieren respuestas de consulta de milisegundos de un solo dígito. Con Timestream para InfluxDB, obtiene el beneficio de las API de código abierto y de un amplio conjunto de agentes de Telegraf de código abierto para recopilar datos de serie temporal. No necesita administrar tareas complejas y que requieren mucho tiempo, como la instalación, las actualizaciones, el almacenamiento, la replicación para una alta disponibilidad y las copias de seguridad de InfluxDB.

Timestream para InfluxDB proporciona un SLA del 99,9 % de disponibilidad cuando se implementa con una configuración multi-AZ y un 99,5 % de disponibilidad para una configuración single-AZ.

Timestream para InfluxDB está diseñado para casos de uso de serie temporal casi en tiempo real. Según las configuraciones de la instancia y las características de las cargas de trabajo, puede esperar una latencia de escritura a lectura de aproximadamente 1 segundo y una latencia de consulta de milisegundos de un solo dígito.

Para migrar a Timestream para InfluxDB desde una instancia de InfluxDB autoadministrada, simplemente puede restaurar una copia de seguridad de una base de datos de InfluxDB existente en una instancia de Timestream para InfluxDB con unos minutos de tiempo de inactividad. Puede reconfigurar sus agentes de recopilación de datos, como los agentes de Telegraf de código abierto, para dirigirse al punto de conexión de InfluxDB administrado por Timestream para InfluxDB. Las tecnologías de paneles, como la interfaz de usuario de InfluxDB, Grafana autohospedado o Amazon Managed Grafana, seguirán funcionando configurándolas para usar el punto de conexión de Timestream para InfluxDB sin ningún otro cambio de código.

Para migrar de Timestream para LiveAnalytics a Timestream para InfluxDB, puede exportar sus datos de Timestream para LiveAnalytics a Amazon S3, realizar las modificaciones necesarias en los archivos CSV exportados y cargarlos en Timestream para InfluxDB.

Se puede concebir una instancia de base de datos como un entorno de base de datos en la nube con los recursos de computación y almacenamiento que usted especifique. Puede crear y eliminar instancias de base de datos, definir y refinar los atributos de infraestructura de sus instancias de base de datos y controlar el acceso y la seguridad a través de la consola de administración de AWS, las API de Timestream para InfluxDB y la AWS CLI. Puede ejecutar una o más instancias de base de datos y cada instancia de base de datos puede admitir una o más bases de datos (buckets) u organizaciones, según las características de la carga de trabajo y la configuración de la instancia.

Las instancias de base de datos son fáciles de crear con la consola de administración de AWS, las API de Timestream para InfluxDB o la AWS CLI. Para iniciar una instancia de base de datos con la consola de administración de AWS, elija bases de datos de InfluxDB y, a continuación, seleccione el botón Crear base de datos de InfluxDB en el panel. Desde allí, puede especificar los parámetros de su instancia de base de datos, incluidos el tipo de instancia, el tipo y la cantidad de almacenamiento, las credenciales de usuario principal, etc.

Si lo prefiere, puede crear la instancia de base de datos mediante la API CreateDBInstance o el comando create-db-instance.

Una vez que la instancia de base de datos esté disponible, puede recuperar su punto de conexión mediante la descripción de la instancia de base de datos en la consola de administración de AWS, la API GetDBInstance o el comando get-db-instance. Al usar este punto de conexión más su token de acceso, puede usar las API de InfluxDB para enviar solicitudes de escritura y lectura, así como administrar el motor con su herramienta de base de datos o lenguaje de programación favorito. También puede acceder a la interfaz de usuario de InfluxDB desde su navegador con ese mismo punto de conexión. Para permitir solicitudes de red en la instancia de base de datos en ejecución, deberá autorizar el acceso o habilitar el acceso a IP pública.

De forma predeterminada, puede tener hasta un total de 40 instancias de Timestream para InfluxDB.

Solo tiene que pagar por lo que use; no hay tarifas mínimas ni de configuración. Su facturación se realiza según los siguientes aspectos:

• Horas de instancia de base de datos: según la clase (por ejemplo, db.influx.large y db.influx.4xlarge) de la instancia de base de datos consumida. Las horas de instancia de la base de datos parciales que se utilicen se facturan en incrementos de 1 segundo, con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de la base de datos.
• Almacenamiento (por GB al mes): capacidad de almacenamiento aprovisionada en la instancia de la base de datos. Si escala la capacidad de almacenamiento aprovisionada durante el mes, se incluirá en la factura el precio prorrateado correspondiente.
• Transferencia de datos: transferencia de datos de Internet desde la instancia de la base de datos y hacia ella.

Para obtener información sobre los precios de Timestream para InfluxDB, visite la página de precios.

La facturación de una instancia de base de datos comienza en cuanto está disponible. La facturación continúa hasta que la instancia de la base de datos se detiene, lo que ocurriría al eliminarla o en caso de error de la instancia.

Las horas de instancia de base de datos se facturan por cada hora en que la instancia se ejecuta en estado de disponibilidad. Si no desea que se le siga cobrando una instancia de base de datos, debe detenerla o eliminarla para que no se facturen más horas de instancia. Las horas de instancia de la base de datos parciales que se utilicen se facturan en incrementos de 1 segundo, con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de la base de datos.

Mientras la instancia de base de datos esté detenida, se le cobrará por el almacenamiento aprovisionado, pero no por las horas de la instancia de base de datos.

Si especifica que su instancia de base de datos debe ser una implementación multi-AZ, se le facturará en función de los precios de multi-AZ publicados en la página de precios de Timestream para InfluxDB. La facturación multi-AZ se basa en lo siguiente:

• Horas de instancia de base de datos multi-AZ: según la clase (por ejemplo, db.influx.large y db.influx.4xlarge) de la instancia de base de datos consumida. Del mismo modo que con las implementaciones estándar en una zona de disponibilidad individual, las horas de instancia de base de datos parciales se facturan en incrementos de 1 segundo con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de la base de datos. Si convierte su implementación de instancia de base de datos entre estándar y multi-AZ en un plazo inferior a una hora, se le cobrarán por dicha hora las dos tarifas aplicables.
• Almacenamiento aprovisionado (para instancias de base de datos multi-AZ): si convierte su implementación entre estándar y multi-AZ en un plazo inferior a una hora, se le cobrará la mayor de las tarifas de almacenamiento aplicables por esa hora.
• Transferencia de datos: no se le cobrarán las transferencias de datos en las que incurra durante la replicación de datos entre la instancia principal y la instancia en espera. Las transferencia de datos de Internet, tanto interna como externa, de su instancia de base de datos tiene el mismo precio que una implementación estándar.

Si no se especifica lo contrario, nuestros precios no incluyen los impuestos ni gravámenes correspondientes, como el IVA y cualquier otro impuesto sobre las ventas. Para los clientes con una dirección de facturación japonesa, el uso de los servicios de AWS está sujeto al impuesto sobre el consumo japonés. 

• Su factura del clúster de réplica de lectura de Timestream para InfluxDB se calcula por instancia dentro del clúster, de acuerdo con los precios que figuran en la página de precios de Timestream para InfluxDB. La estructura de facturación consta de cuatro componentes principales:
  Las horas de nodo del clúster se cobran en función de la clase de instancia que haya seleccionado (por ejemplo, db.influx.large o db.influx.4xlarge). Facturamos en incrementos de 1 segundo con un cargo mínimo de 10 minutos después de cualquier cambio de estado facturable, incluidas las modificaciones de creación, inicio o clase de instancia. Si realiza la conversión entre tipos de clústeres en el plazo de una hora, se le cobrarán las dos tarifas aplicables durante ese periodo.
• En cuanto al almacenamiento, se le facturará en función de la capacidad aprovisionada. Al realizar la conversión entre tipos de implementación (clúster, estándar o base de datos multi-AZ) en el plazo de una hora, aplicamos la tarifa de almacenamiento aplicable más alta para esa hora.
• En cuanto a la transferencia de datos, no incurrirá en cargos por la replicación de datos entre las instancias principales y de réplica. Sin embargo, la transferencia de datos de Internet hacia y desde su clúster de base de datos sigue los mismos precios que las implementaciones estándar.
• La funcionalidad de la réplica de lectura se proporciona a través de un complemento con licencia creado y vendido por InfluxData y que se activará a través de AWS Marketplace. Esta licencia funciona según un modelo de pago por uso, con cargos basados en las horas de instancia según la cantidad de vCPU en la clase de instancia configurada.
  

Para seleccionar la clase de instancia de base de datos y la capacidad de almacenamiento iniciales, debe evaluar las necesidades de cómputo, memoria y almacenamiento de la aplicación. Para obtener información sobre las clases de instancias de base de datos disponibles, consulte la Guía del usuario de Timestream para InfluxDB.

El almacenamiento incluido de IOPS de Timestream para InfluxDB es una opción de almacenamiento con respaldo SSD diseñada para proporcionar un rendimiento de E/S rápido, predecible y constante. Con el almacenamiento incluido de IOPS de Timestream para InfluxDB, tiene tres niveles para elegir, que van desde cargas de trabajo pequeñas hasta cargas de trabajo optimizadas para el alto rendimiento a gran escala. Solo debe especificar el tamaño del volumen asignado al nivel que mejor se adapte a sus necesidades. El almacenamiento incluido de IOPS de Timestream para InfluxDB está optimizado para cargas de trabajo de bases de datos transaccionales (OLTP) con uso intensivo de I/O. Para obtener más información, consulte la Guía del usuario de Timestream para InfluxDB.

Elija el tipo de almacenamiento que mejor se ajuste a su carga de trabajo.

• Cargas de trabajo OLTP de alto rendimiento: IOPS de Timestream para InfluxDB, incluido el almacenamiento.

Por defecto, Timestream para InfluxDB elige los parámetros de configuración óptimos para su instancia de base de datos. Para ello, tiene en cuenta la clase de instancia y la capacidad de almacenamiento. Sin embargo, si desea cambiarlos, puede hacerlo mediante la consola de administración de AWS, las API de Timestream para InfluxDB o la AWS CLI. Recuerde que modificar los parámetros de configuración recomendados puede tener efectos no deseados, como la reducción del rendimiento y bloqueos del sistema, y solo los usuarios avanzados que deseen asumir estos riesgos podrán hacerlo.

En el momento del lanzamiento, proporcionaremos un conjunto limitado de parámetros que podrá modificar, entre los que se incluyen:flux-log-enabled, log-level, metrics-disable, no-tasks, query-concurrency, query-queue-size y tracing-type. Esta lista puede crecer con el tiempo en función de los requisitos de los clientes.

Un grupo de parámetros de base de datos actúa como contenedor de valores de configuración del motor que pueden aplicarse a una o varias instancias de bases de datos. Si crea una instancia de base de datos sin especificar un grupo de parámetros de bases de datos, se utilizará un grupo de parámetros de bases de datos predeterminado. Este grupo predeterminado contiene los valores predeterminados del motor y los valores predeterminados del sistema de Timestream para InfluxDB optimizados para la instancia de base de datos que está ejecutando.

Sin embargo, si desea que su instancia de base de datos funcione con valores de configuración de motor personalizados, basta con que cree un nuevo grupo de parámetros de bases de datos, modifique los parámetros que desee y modifique la instancia de base de datos para que utilice el nuevo grupo de parámetros de bases de datos. 

Cuando cree su instancia de la base de datos para que se ejecute como una implementación multi-AZ o la modifique con ese fin, Timestream para InfluxDB aprovisionará automáticamente una réplica en espera sincrónica dentro de una zona de disponibilidad diferente y la administrará. Las actualizaciones de su instancia de la base de datos se replican de forma sincrónica en las zonas de disponibilidad en espera, con el fin de mantener ambas bases de datos sincronizadas y proteger las actualizaciones más recientes de su base de datos de errores de la instancia. 

Durante determinados tipos de mantenimiento planificado, o en el improbable caso de que se produzca un error en la instancia de base de datos o la zona de disponibilidad, Timestream para InfluxDB conmutará por error automáticamente a la instancia en espera para que pueda reanudar las escrituras y lecturas en la base de datos en cuanto se comience a usar la instancia en espera. Dado que el registro de nombre de su instancia de base de datos no se verá modificado, su aplicación podrá reanudar la operación de la base de datos sin necesidad de intervención administrativa manual.

Además, en las implementaciones multi-AZ, la replicación es transparente. No se interactúa directamente con la instancia en espera, y esta no puede utilizarse para atender tráfico de lectura.

Las zonas de disponibilidad son ubicaciones concretas dentro de una región que están diseñadas para estar aisladas de errores que se produzcan en otras zonas de disponibilidad. Cada zona de disponibilidad se ejecuta en su propia infraestructura, independiente y físicamente distinta, y está diseñada para ofrecer un nivel de fiabilidad alto. Los puntos comunes de error, como los generadores y el equipo de enfriamiento, no se comparten entre zonas de disponibilidad. Además, se encuentran en ubicaciones físicas diferentes, de forma que, incluso los desastres extremadamente poco frecuentes, como incendios, tornados o inundaciones, solo afecten a una sola zona de disponibilidad. Las zonas de disponibilidad que se encuentran dentro de la misma región disfrutan de conectividad a red de baja latencia.

Cuando ejecuta una instancia de base de datos como una implementación multi-AZ, la instancia “principal” atiende las escrituras y lecturas de la base de datos. Además, Timestream para InfluxDB aprovisiona y mantiene una instancia “en espera” en segundo plano, que es una réplica actualizada de la instancia principal. En situaciones de conmutación por error, la instancia en espera se transforma en principal. Tras la conmutación por error, la réplica en espera pasa a ser la principal y acepta las operaciones de base de datos. Usted no interactuará directamente con la instancia en espera (por ejemplo, para operaciones de lectura) antes de que se transforme en principal.

Los principales beneficios de ejecutar su instancia de base de datos como una implementación multi-AZ son la mejora de la durabilidad y la disponibilidad de la base de datos. El mayor nivel de disponibilidad y tolerancia a errores que ofrecen las implementaciones Multi-AZ las convierten en una opción ideal para los entornos de producción.

La ejecución de su instancia de base de datos como una implementación multi-AZ protege sus datos en el improbable caso de que se produzca un error en un componente de la instancia de base de datos o una pérdida de disponibilidad en una zona de disponibilidad.

Por ejemplo, si uno de los volúmenes de almacenamiento de su instancia principal falla, Timestream para InfluxDB inicia automáticamente un proceso de conmutación por error hacia la instancia en espera, en la que todas las actualizaciones de la base de datos están intactas. Esta función proporciona durabilidad de datos adicional respecto a las implementaciones estándar de una única zona de disponibilidad. Se necesitaría una operación de restauración iniciada por el usuario y no estarían disponibles las actualizaciones producidas tras el tiempo restaurable más reciente (normalmente dentro de los últimos 5 minutos).

También se beneficia de un mayor nivel de disponibilidad de la base de datos cuando ejecuta su instancia de base de datos como una implementación multi-AZ. Si se produce un error en la zona de disponibilidad o falla una instancia de base de datos, la repercusión en la disponibilidad estará limitada al tiempo que tarda en completarse la conmutación por error automática. Los beneficios de disponibilidad de multi-AZ también se trasladan a las tareas de mantenimiento planificadas. Otro de los beneficios implícitos de la ejecución de su instancia de base de datos como una implementación multi-AZ es que la conmutación por error de la instancia de base de datos es automática y no necesita ningún tipo de administración. 

Es posible que observe latencias elevadas en relación con las implementaciones de instancias de base de datos estándar en una zona de disponibilidad única, como consecuencia de la replicación de datos sincrónica que se realiza por usted.

No, una instancia de espera multi-AZ no puede atender solicitudes de lectura. Las implementaciones Multi-AZ están diseñadas para ofrecer mayores niveles de disponibilidad y durabilidad de la base de datos, en lugar de beneficios de escalado de lectura. Por ello, la función utiliza replicación sincrónica entre la versión principal y la versión en espera. Nuestra implementación garantiza que la versión principal y la versión en espera estén constantemente sincronizadas, pero impide utilizar la versión en espera para operaciones de lectura o escritura.

Para crear una implementación de instancia de base de datos multi-AZ, solo tiene que hacer clic en la opción “Sí” de “Despliegue multi-AZ” al iniciar una instancia de base de datos con la Consola de administración de AWS. Si utiliza las API de Timestream para InfluxDB, también puede realizar una llamada a la API CreateDBInstance y configurar el parámetro Multi-AZ con el valor True.
También puede modificar una de sus instancias existentes y establecer el tipo de implementación en multi-AZ.

Las implementaciones multi-AZ de Timestream para InfluxDB detectan las situaciones de error de las implementaciones multi-AZ más comunes y se recuperan automáticamente, por lo que puede restablecer las operaciones de base de datos de la manera más rápida posible sin necesidad de intervención administrativa alguna. Timestream para InfluxDB realiza automáticamente una conmutación por error en los siguientes casos:

• Pérdida de disponibilidad en la zona de disponibilidad principal
• Pérdida de conectividad de red con la instancia principal
• Error de unidad informática en la instancia
• Error de almacenamiento en la instancia principal

Tenga en cuenta que las implementaciones multi-AZ de Timestream para InfluxDB no conmutan por error automáticamente en respuesta a operaciones de base de datos, como consultas de larga duración, bloqueos o errores de daños en bases de datos.

Timestream para InfluxDB administra automáticamente la conmutación por error para que pueda reanudar las operaciones de la base de datos a la mayor brevedad posible y sin intervención administrativa Durante la conmutación por error, Timestream para InfluxDB simplemente cambia el registro de nombre canónico (CNAME) de su instancia de base de datos para que apunte a la versión en espera, que se convierte en la nueva versión principal. Le instamos a que siga las prácticas recomendadas e implemente el reintento de conexión de la base de datos en la capa de la aplicación.

Las conmutaciones por error, definidas por el intervalo que transcurre entre la detección del error en la instancia principal y la reanudación de las transacciones en la instancia en espera, suelen tardar un par de minutos. El tiempo de conmutación por error también puede verse afectado por la necesidad de recuperar transacciones grandes y no comprometidas, el tamaño del índice y otros factores. Se recomienda el uso de tipos de instancias suficientemente grandes con multi-AZ para obtener mejores resultados. AWS también recomienda el uso de Timestream para InfluxDB para el almacenamiento incluido de IOPS con instancias multi-AZ para lograr un rendimiento de procesamiento rápido, predecible y uniforme.

Timestream para InfluxDB realiza conmutaciones por error automáticas sin necesidad de que intervenga el usuario bajo determinadas condiciones de error. En este momento, no puede iniciar manualmente una conmutación por error forzada de su instancia de base de datos de Timestream para InfluxDB.

En las implementaciones multi-AZ, únicamente tiene que establecer el parámetro “Multi-AZ” en “true”. La creación de la versión en espera, la replicación sincrónica y la conmutación por error se administran de forma automática. Esto implica que no podrá seleccionar la zona de disponibilidad en la que se implementa su versión en espera, ni tampoco alterar el número de versiones en espera disponibles (Timestream para InfluxDB aprovisiona una versión en espera dedicada por cada versión principal de instancia de base de datos). Además, la versión en espera no puede configurarse para que acepte actividad de lectura de base de datos.

Sí, la versión en espera se aprovisionará de forma automática en una zona de disponibilidad diferente dentro de la misma región que la instancia de base de datos principal.

Sí, puede ver la ubicación de la instancia principal actual con la Consola de administración de AWS o la API GetDBInstance.

Las zonas de disponibilidad están diseñadas para ofrecer conectividad de red de baja latencia con otras zonas de disponibilidad que se encuentren dentro de la misma región. Además, es posible que desee barajar la posibilidad de diseñar su aplicación y otros recursos de AWS con redundancia entre varias zonas de disponibilidad, de forma que su aplicación sea resiliente en caso de producirse un error en una zona de disponibilidad. Las implementaciones multi-AZ afrontan esta necesidad de la capa de la base de datos sin administración por su parte.

Un clúster de réplica de lectura de Timestream para InfluxDB proporciona una mayor disponibilidad y escalabilidad de lectura para su base de datos. Al crear un clúster, Timestream para InfluxDB aprovisiona y mantiene automáticamente al menos una réplica legible asincrónica en una zona de disponibilidad diferente. Las actualizaciones de su nodo principal se replican de forma asincrónica en estas réplicas de lectura, lo que le permite distribuir la carga de trabajo de las consultas entre varios nodos.

El clúster admite la conmutación por error automática durante el mantenimiento planificado o en el improbable caso de que se produzca un error en un nodo o una zona de disponibilidad. Cuando se produce una conmutación por error, las aplicaciones pueden seguir funcionando sin intervención manual, ya que los puntos de conexión de escritura y lectura mantienen los mismos registros de nombres. Sin embargo, es importante tener en cuenta que, durante el periodo de recuperación, mientras restauramos el nodo que ha fallado y lo restablecemos como réplica de lectura, las aplicaciones que utilicen los puntos de conexión del nodo de réplica para la lectura no estarán disponibles temporalmente.

En un clúster de réplica de lectura, el nodo principal gestiona todas las escrituras, lecturas y administración de las funciones administrativas y configuraciones específicas del motor en la base de datos. Además, Timestream para InfluxDB aprovisiona y mantiene automáticamente una réplica de lectura que se mantiene actualizada con el nodo principal. La réplica de lectura tiene dos propósitos principales: amplía la capacidad de lectura al aceptar solicitudes de lectura adicionales y puede ascender a principal en situaciones de conmutación por error. Durante un evento de conmutación por error, cuando la réplica de lectura se convierte en principal, se hace cargo de todas las operaciones de la base de datos. Una vez que el nodo que había fallado anteriormente vuelve a estar operativo, vuelve a unirse al clúster como una réplica de lectura, lo que mantiene la resiliencia del clúster.

Los clústeres de réplicas de lectura ofrecen tres ventajas clave: escalabilidad mejorada, disponibilidad mejorada y optimización de la carga de trabajo. El aumento de la escalabilidad se debe a la capacidad de distribuir las cargas de trabajo de lectura en varios nodos del clúster, lo que lo hace especialmente valioso para las aplicaciones en las que los requisitos de lectura superan con creces las operaciones de escritura.

Cuando se configuran con la conmutación por error habilitada, los clústeres de réplicas de lectura proporcionan una mayor disponibilidad mediante capacidades de conmutación por error más rápidas. Como todos los nodos del clúster permanecen activos, puede convertir una réplica en principal sin esperar a que se inicie el nodo, lo que minimiza el tiempo de inactividad durante los escenarios de conmutación por error.

Además, los clústeres de réplicas de lectura permiten una administración eficiente de las cargas de trabajo Puede dedicar su nodo principal a gestionar consultas sencillas y rápidas que normalmente se utilizan para paneles, alarmas y notificaciones en tiempo real, al tiempo que dirige las consultas analíticas más complejas a sus réplicas de lectura. Esta separación garantiza un rendimiento óptimo para diferentes tipos de cargas de trabajo.

El proceso replicador ha demostrado un impacto insignificante en el rendimiento, con un efecto mínimo en el consumo de CPU o memoria. Sin embargo, es importante tener en cuenta que el retraso de la replicación (el tiempo entre el momento en que se acepta un registro en el servidor principal y el momento en que pasa a estar disponible en las réplicas de lectura) puede variar según el nivel de carga de los nodos de réplica.

Timestream para InfluxDB publica una métrica de CloudWatch denominada “ReplicaLag” que le ayuda a supervisar el estado de sincronización de sus réplicas de lectura. Esta métrica, medida en milisegundos, registra qué tan atrasadas están las réplicas con respecto al nodo principal. La latencia de replicación puede verse afectada por los niveles de carga de la base de datos, por lo que recomendamos a los clientes que supervisen activamente esta métrica para asegurarse de que sus réplicas de lectura mantengan niveles de sincronización aceptables para su caso de uso.

Para configurar un clúster de réplicas de lectura en Timestream para InfluxDB, comience por iniciar sesión en la consola de administración de AWS y navegar hasta la consola de Amazon Timestream. Elija “Crear base de datos de InfluxDB” en la sección Bases de datos de InfluxDB. Al configurar los ajustes de implementación, seleccione “Clúster de base de datos con réplicas de lectura”. Deberá activar una suscripción a través de AWS Marketplace, que requiere los permisos AWSMarketplaceManageSubscriptions o AWSMarketplaceFullAccess. Tras confirmar la suscripción, proporcione los detalles básicos de configuración y seleccione las clases de nodo y almacenamiento adecuadas que se aplicarán a todos los nodos del clúster.

No, en un clúster de réplica de lectura, solo puede haber un nodo principal que gestione las operaciones de escritura en un momento dado. El nodo principal atiende todas las solicitudes de escritura y, al mismo tiempo, administra las lecturas de bases de datos, las configuraciones específicas del motor y las funciones administrativas. Las réplicas de lectura se mantienen actualizadas con este nodo principal y solo pueden aceptar solicitudes de lectura. Si bien puede promover una réplica de lectura para que se convierta en la principal durante los escenarios de conmutación por error, la arquitectura del clúster mantiene un modelo de un solo escritor para garantizar la coherencia de datos.

Para los clústeres de réplicas de lectura, puede habilitar o desactivar la característica de conmutación por error durante la creación o modificación del clúster. Cuando está habilitado, Timestream para InfluxDB gestiona automáticamente la administración de los procesos de réplicas, replicación y conmutación por error. No puede seleccionar zonas de disponibilidad específicas para sus réplicas y Timestream para InfluxDB mantiene al menos una réplica de lectura por clúster. Las réplicas de lectura aceptan activamente las solicitudes de lectura para ayudar a distribuir la carga de trabajo.

Timestream para InfluxDB detecta los escenarios de error comunes y se recupera automáticamente en las implementaciones de clústeres de réplicas de lectura, lo que le permite reanudar las operaciones de la base de datos rápidamente sin intervención administrativa. El sistema realiza automáticamente una conmutación por error a una réplica de lectura en caso de que se produzca alguna de las siguientes situaciones:

• Pérdida de disponibilidad en la zona de disponibilidad del nodo principal
• Pérdida de conectividad de red al nodo principal
• Fallo de la unidad informática en el nodo principal
• Fallo de almacenamiento en el nodo principal

Nota: Los clústeres de réplica de lectura de Timestream para InfluxDB no se conmutan por error automáticamente en respuesta a las operaciones de la base de datos, como consultas de ejecución prolongada, bloqueos o errores de daños en bases de datos. Recuerde que la conmutación por error automática solo se realizará si ha habilitado específicamente esta característica para su clúster de réplica de lectura durante la configuración o mediante la modificación del clúster.

Timestream para InfluxDB gestiona automáticamente la conmutación por error en un clúster de réplica de lectura cuando la característica está habilitada, lo que permite que las operaciones de la base de datos se reanuden rápidamente sin intervención administrativa. Durante la conmutación por error, Timestream para InfluxDB actualiza el registro de nombre canónico (CNAME) de su base de datos para que apunte a la réplica de lectura, que luego se promueve para convertirse en la nueva principal. Recomendamos implementar la lógica de reintento de conexión a la base de datos en la capa de aplicación como práctica recomendada.

Debido a que los nodos de un clúster de réplica de lectura están activos, el tiempo de conmutación por error se mantendrá estable independientemente de las características de la carga de trabajo. Por lo general, las conmutaciones por error se completan en unos pocos minutos, desde la detección del error principal hasta la reanudación de las transacciones en la réplica promocionada. Para un rendimiento óptimo, recomendamos utilizar tipos de nodos de tamaño adecuado y el almacenamiento incluido de IOPS de Timestream para InfluxDB.

Cuando la conmutación por error está habilitada, Timestream para InfluxDB gestiona automáticamente la conmutación por error en diversas condiciones de error. Actualmente, no se admite el inicio manual de la conmutación por error forzada en los clústeres de réplicas de lectura de Timestream para InfluxDB.

Sí, la réplica de lectura se aprovisionará de forma automática en una zona de disponibilidad diferente dentro de la misma región que el nodo principal.

Sí, puede ver la ubicación de sus nodos principales y de réplica de lectura a través de la consola de administración de AWS o mediante la API GetDBInstance.

Las zonas de disponibilidad están diseñadas para ofrecer conectividad de red de baja latencia con otras zonas de disponibilidad que se encuentren dentro de la misma región, por lo que el impacto de la latencia debe ser mínimo. Sin embargo, recomendamos diseñar su aplicación y otros recursos de AWS con redundancia en varias zonas de disponibilidad para lograr la máxima resiliencia. Los clústeres de réplicas de lectura admiten esta arquitectura de forma natural, ya que puede distribuir las cargas de trabajo de lectura entre los nodos de diferentes zonas de disponibilidad y, cuando la conmutación por error está habilitada, la aplicación puede seguir funcionando incluso si una zona de disponibilidad deja de estar disponible.