Consideraciones sobre la plataforma de datos para cargas de trabajo críticas en Azure

La selección de una plataforma de datos de aplicación eficaz es un área de decisión más crucial, que tiene implicaciones de gran alcance en otras áreas de diseño. En última instancia, Azure ofrece una gran variedad de plataformas de datos relacionales, no relacionales y analíticas, que difieren en gran medida en la funcionalidad. Por lo tanto, es esencial que los requisitos clave no funcionales se consideren completamente junto con otros factores de decisión, como la coherencia, la operabilidad, el costo y la complejidad. Por ejemplo, la capacidad de operar en una configuración de escritura en varias regiones tendrá un efecto crítico sobre la idoneidad de una plataforma disponible globalmente.

Este área de diseño se expande en el diseño de aplicaciones, lo que proporciona consideraciones clave y recomendaciones para informar a la selección de una plataforma de datos óptima.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected . Si no está familiarizado con esta serie, se recomienda empezar con lo que es una carga de trabajo crítica?

Los cuatro frente a los macrodatos

Los "Cuatro frentes a macrodatos" proporcionan un marco para comprender mejor las características necesarias para una plataforma de datos de alta disponibilidad y cómo se pueden usar los datos para maximizar el valor empresarial. Por lo tanto, en esta sección se explorará cómo se pueden aplicar las características de Volumen, Velocidad, Variedad y Veracity en un nivel conceptual para ayudar a diseñar una plataforma de datos mediante tecnologías de datos adecuadas.

• Volume: la cantidad de datos que llegan para informar a los requisitos de capacidad de almacenamiento y niveles, que es el tamaño del conjunto de datos.
• Velocity: la velocidad a la que se procesan los datos, ya sea como lotes o flujos continuos, que es la velocidad del flujo.
• Variety: la organización y el formato de los datos, la captura de formatos estructurados, semiestructurados y no estructurados, que son datos en varios almacenes o tipos.
• Veracity: incluye la procedencia y la curación de los conjuntos de datos considerados para la gobernanza y la garantía de calidad de los datos, que es la precisión de los datos.

Consideraciones de diseño

Volumen

• Existente (si existe) y volúmenes de datos futuros esperados en función de las tasas de crecimiento de datos previstas alineadas con los objetivos y planes empresariales.

  • El volumen de datos debe abarcar los propios datos e índices, registros, telemetría y otros conjuntos de datos aplicables.
  • Las aplicaciones críticas para la empresa y críticas para la empresa suelen generar y almacenar grandes volúmenes (GB y TB) diariamente.
  • Puede haber implicaciones de costos significativas asociadas a la expansión de datos.

• El volumen de datos puede fluctuar debido a las circunstancias empresariales cambiantes o a los procedimientos de limpieza.

• El volumen de datos puede tener un impacto profundo en el rendimiento de las consultas de la plataforma de datos.

• Puede haber un impacto profundo asociado a alcanzar los límites de volumen de la plataforma de datos.

  • ¿Dará lugar a un tiempo de inactividad? y si es así, ¿durante cuánto tiempo?
  • ¿Cuáles son los procedimientos de mitigación? y ¿la mitigación requerirá cambios en la aplicación?
  • ¿Habrá riesgo de pérdida de datos?

• Características como período de vida (TTL) se pueden usar para administrar el crecimiento de los datos mediante la eliminación automática de registros después de un tiempo transcurrido, mediante la creación o modificación de registros.

  • Por ejemplo, Azure Cosmos DB proporciona una funcionalidad TTL integrada.

Velocidad

• La velocidad con la que se emiten los datos de varios componentes de la aplicación y los requisitos de rendimiento para la rapidez con la que se deben confirmar y recuperar los datos son fundamentales para determinar una tecnología de datos óptima para escenarios clave de carga de trabajo.

  • La naturaleza de los requisitos de rendimiento variará en función del escenario de carga de trabajo, como las que son de lectura intensiva o de escritura intensiva.
    • Por ejemplo, las cargas de trabajo analíticas normalmente tendrán que satisfacer un gran rendimiento de lectura.
  • ¿Cuál es el rendimiento necesario? ¿Y cómo se espera que crezca el rendimiento?
  • ¿Cuáles son los requisitos de latencia de datos en P50/P99 bajo los niveles de carga de referencia?

• Las funcionalidades como admitir un diseño sin bloqueo, la optimización de índices y las directivas de coherencia son fundamentales para lograr un alto rendimiento.

  • La optimización de la configuración para un alto rendimiento conlleva inconvenientes, lo que debe entenderse por completo.
  • Los patrones de persistencia y mensajería de nivel de carga, como CQRS y Event Sourcing, se pueden usar para optimizar aún más el rendimiento.

• Los niveles de carga fluctúan naturalmente para muchos escenarios de aplicación, con picos naturales que requieren un grado suficiente de elasticidad para controlar la demanda variable y mantener el rendimiento y la latencia.

  • La escalabilidad ágil es clave para admitir eficazmente niveles de carga y rendimiento variable sin sobreaprovisionar niveles de capacidad.
    • Tanto el rendimiento de lectura como de escritura deben escalarse según los requisitos de la aplicación y la carga.
    • Las operaciones de escalado vertical y horizontal se pueden aplicar para responder a los niveles de carga cambiantes.

• El impacto de las interrupciones de rendimiento puede variar en función del escenario de carga de trabajo.

  • ¿Habrá interrupciones de conectividad?
  • ¿Las operaciones individuales devolverán códigos de error mientras el plano de control sigue funcionando?
  • ¿La plataforma de datos activará la limitación y, si es así, durante cuánto tiempo?

• La recomendación fundamental de diseño de aplicaciones para usar una distribución geográfica activa-activa presenta desafíos en torno a la coherencia de los datos.

  • Existe un equilibrio entre la coherencia y el rendimiento con respecto a la semántica transaccional ACID completa y el comportamiento de bloqueo tradicional.
    • La minimización de la latencia de escritura tendrá el costo de la coherencia de los datos.

• En una configuración de escritura de varias regiones, los cambios tendrán que sincronizarse y combinarse entre todas las réplicas, con resolución de conflictos cuando sea necesario, y esto puede afectar a los niveles de rendimiento y a la escalabilidad.

• Las réplicas de solo lectura (dentro de la región y entre regiones) se pueden usar para minimizar la latencia de ida y vuelta y distribuir el tráfico para aumentar el rendimiento, el rendimiento, la disponibilidad y la escalabilidad.

• Se puede usar una capa de almacenamiento en caché para aumentar el rendimiento de lectura para mejorar la experiencia del usuario y los tiempos de respuesta de cliente de un extremo a otro.

  • Es necesario tener en cuenta las directivas y los tiempos de expiración de caché para optimizar la recienteidad de los datos.

Variedad

• El modelo de datos, los tipos de datos, las relaciones de datos y el modelo de consulta previsto afectarán significativamente a las decisiones de la plataforma de datos.

  • ¿La aplicación requiere un modelo de datos relacionales o puede admitir un esquema de variables o un modelo de datos no relacional?
  • ¿Cómo consultarán los datos de la aplicación? ¿Y las consultas dependerán de conceptos de capa de base de datos, como combinaciones relacionales? ¿O la aplicación proporciona esa semántica?

• La naturaleza de los conjuntos de datos considerados por la aplicación puede variar, desde contenido no estructurado, como imágenes y vídeos, o archivos más estructurados, como CSV y Parquet.

  • Las cargas de trabajo de aplicaciones compuestas suelen tener conjuntos de datos distintivos y requisitos asociados.

• Además de las plataformas de datos relacionales o no relacionales, las plataformas de datos de grafos o clave-valor también pueden ser adecuadas para determinadas cargas de trabajo de datos.

  • Algunas tecnologías satisfacen los modelos de datos de esquema variable, donde los elementos de datos son semánticamente similares o almacenados y consultados juntos, pero difieren estructuralmente.

• En una arquitectura de microservicios, los servicios de aplicación individuales se pueden crear con almacenes de datos distintos optimizados para escenarios en lugar de depender de un único almacén de datos monolítico.

  • Los patrones de diseño como SAGA se pueden aplicar para administrar la coherencia y las dependencias entre diferentes almacenes de datos.
    • Las consultas directas entre bases de datos pueden imponer restricciones de colocalización.
  • El uso de varias tecnologías de datos agregará un grado de sobrecarga de administración para mantener tecnologías abarcadas.

• Los conjuntos de características de cada servicio de Azure difieren entre idiomas, SDK y API, lo que puede afectar considerablemente al nivel de ajuste de configuración que se puede aplicar.

• Las funcionalidades para la alineación optimizada con el modelo de datos y los tipos de datos incluidos influirán fuertemente en las decisiones de la plataforma de datos.

  • Capas de consulta, como procedimientos almacenados y asignadores relacionales de objetos.
  • Funcionalidad de consulta independiente del lenguaje, como una capa de API REST protegida.
  • Funcionalidades de continuidad empresarial, como la copia de seguridad y la restauración.

• Los almacenes de datos analíticos suelen admitir el almacenamiento poliglot para varios tipos de estructuras de datos.

  • Los entornos de tiempo de ejecución analíticos, como Apache Spark, pueden tener restricciones de integración para analizar estructuras de datos poliglot.

• En un contexto empresarial, el uso de procesos y herramientas existentes, y la continuidad de las aptitudes, puede tener un impacto significativo en el diseño de la plataforma de datos y la selección de tecnologías de datos.

Veracidad

• Se deben tener en cuenta varios factores para validar la precisión de los datos dentro de una aplicación y la administración de estos factores puede tener un efecto significativo en el diseño de la plataforma de datos.

  • Coherencia de datos
  • Características de seguridad de la plataforma.
  • Gobernanza de datos.
  • Evolución del esquema y la administración de cambios.
  • Dependencias entre conjuntos de datos.

• En cualquier aplicación distribuida con varias réplicas de datos hay un equilibrio entre la coherencia y la latencia, tal como se expresa en los teoremas CAP y PACELC .

  • Cuando los lectores y escritores se distribuyen de forma distinta, una aplicación debe optar por devolver la versión más rápida disponible de un elemento de datos, incluso si no está actualizada en comparación con una escritura (actualización) just-completed de ese elemento de datos en otra réplica o la versión más actualizada del elemento de datos, lo que puede incurrir en latencia adicional para determinar y obtener el estado más reciente.
  • La coherencia y la disponibilidad se pueden configurar en el nivel de plataforma o en el nivel de solicitud de datos individuales.
  • ¿Cuál es la experiencia del usuario si los datos se van a servir desde una réplica más cercana al usuario que no refleja el estado más reciente de una réplica diferente? Es decir, ¿la compatibilidad con la aplicación puede servir datos obsoletos?

• En un contexto de escritura de varias regiones, cuando se cambia el mismo elemento de datos en dos réplicas de escritura independientes antes de que se pueda replicar cualquier cambio, se crea un conflicto que se debe resolver.

  • Se pueden aplicar directivas estandarizadas de resolución de conflictos, como "Last Write Wins" o una estrategia personalizada con lógica personalizada.

• La implementación de los requisitos de seguridad puede afectar negativamente al rendimiento o al rendimiento.

• El cifrado en reposo se puede implementar en la capa de aplicación mediante el cifrado del lado cliente o la capa de datos mediante el cifrado del lado servidor si es necesario.

• Azure admite varios modelos de cifrado, incluido el cifrado del lado servidor que usa claves administradas por el servicio, claves administradas por el cliente en Key Vault o claves administradas por el cliente en hardware controlado por el cliente.

  • Con el cifrado del lado cliente, las claves se pueden administrar en Key Vault u otra ubicación segura.

• El cifrado de vínculo de datos MACsec (IEEE 802.1AE MAC) se usa para proteger todo el tráfico que se mueve entre los centros de datos de Azure en la red troncal de Microsoft.

  • Los paquetes se cifran y descifran en los dispositivos antes de enviarse, lo que impide ataques físicos de "tipo man in the middle" o desacoplación de cables.

• Autenticación y autorización en el plano de datos y el plano de control.

  • ¿Cómo autenticará y autorizará la plataforma de datos el acceso a las aplicaciones y el acceso operativo?

• Observabilidad mediante la supervisión del estado de la plataforma y el acceso a los datos.

  • ¿Cómo se aplicarán las alertas para las condiciones fuera de los límites operativos aceptables?

Recomendaciones de diseño

Volumen

• Asegúrese de que los volúmenes de datos futuros asociados al crecimiento orgánico no se espera que superen las funcionalidades de la plataforma de datos.

  • Previsión de las tasas de crecimiento de los datos alineadas con los planes empresariales y uso de tasas establecidas para informar sobre los requisitos de capacidad continuos.
  • Compare los volúmenes de registros agregados y por datos con los límites de la plataforma de datos.
  • Si existe un riesgo de que se alcancen límites en circunstancias excepcionales, asegúrese de que se aplican mitigaciones operativas para evitar tiempos de inactividad y pérdida de datos.

• Supervise el volumen de datos y lo valide con un modelo de capacidad, teniendo en cuenta los límites de escala y las tasas de crecimiento de datos esperadas.

  • Asegúrese de que las operaciones de escalado se alineen con los requisitos de almacenamiento, rendimiento y coherencia.
  • Cuando se introduce una nueva unidad de escalado, es posible que sea necesario replicar los datos subyacentes, lo que tardará tiempo y probablemente introducirá una penalización de rendimiento mientras se produce la replicación. Por lo tanto, asegúrese de que estas operaciones se realizan fuera del horario comercial crítico si es posible.

• Defina los niveles de datos de la aplicación para clasificar los conjuntos de datos en función del uso y la importancia para facilitar la eliminación o descarga de datos más antiguos.

  • Considere la posibilidad de clasificar los conjuntos de datos en niveles "frecuente", "intermedio" y "frío" ("archivo") .
    • Por ejemplo, las implementaciones de referencia fundamentales usan Azure Cosmos DB para almacenar datos "activos" que usa activamente la aplicación, mientras que Azure Storage se usa para datos de operaciones "inactivas" con fines analíticos.

• Configure procedimientos de limpieza para optimizar el crecimiento de los datos e impulsar la eficiencia de los datos, como el rendimiento de las consultas y la administración de la expansión de datos.

  • Configure la expiración del período de vida (TTL) para los datos que ya no son necesarios y no tiene ningún valor analítico a largo plazo.
    • Compruebe que los datos antiguos se pueden organizar en capas de forma segura en el almacenamiento secundario o eliminarse directamente, sin un impacto adverso en la aplicación.
  • Descargue datos no críticos en el almacenamiento en frío secundario, pero mantenlo para el valor analítico y para satisfacer los requisitos de auditoría.
  • Recopile datos de telemetría y estadísticas de uso de la plataforma de datos para permitir que los equipos de DevOps evalúen continuamente los requisitos de mantenimiento y los almacenes de datos de "tamaño correcto".

• En línea con un diseño de aplicaciones de microservicios, considere el uso de varias tecnologías de datos diferentes en paralelo, con soluciones de datos optimizadas para escenarios de carga de trabajo específicos y requisitos de volumen.

  • Evite crear un único almacén de datos monolítico en el que el volumen de datos de la expansión puede ser difícil de administrar.

Velocidad

• La plataforma de datos debe diseñarse y configurarse de forma inherente para admitir un alto rendimiento, con cargas de trabajo separadas en diferentes contextos para maximizar el rendimiento mediante soluciones de datos optimizadas para escenarios.

  • Asegúrese de que el rendimiento de lectura y escritura para cada escenario de datos puede escalar según los patrones de carga esperados, con tolerancia suficiente para una varianza inesperada.
  • Separe diferentes cargas de trabajo de datos, como las operaciones transaccionales y analíticas, en contextos de rendimiento distintos.

• Nivel de carga mediante el uso de mensajería asincrónica sin bloqueo, por ejemplo mediante los patrones CQRS o Event Sourcing .

  • Es posible que haya latencia entre las solicitudes de escritura y cuando los nuevos datos estén disponibles para leerse, lo que puede afectar a la experiencia del usuario.
    • Este impacto debe entenderse y aceptarse en el contexto de los requisitos empresariales clave.

• Garantice la escalabilidad ágil para admitir niveles de carga y rendimiento variables.

  • Si los niveles de carga son muy volátiles, considere la posibilidad de sobreaprovisionar niveles de capacidad para garantizar que se mantenga el rendimiento y el rendimiento.
  • Pruebe y valide el impacto en las cargas de trabajo de aplicaciones compuestas cuando no se puede mantener el rendimiento.

• Priorice los servicios de datos nativos de Azure con operaciones de escalado automatizadas para facilitar una respuesta rápida a la volatilidad de nivel de carga.

  • Configure el escalado automático en función de los umbrales internos del servicio y del conjunto de aplicaciones.
  • El escalado debe iniciarse y completarse en períodos de tiempo coherentes con los requisitos empresariales.
  • En escenarios en los que es necesaria la interacción manual, establezca "cuadernos de estrategias" operativos automatizados que se puedan desencadenar en vez de realizar acciones operativas manuales.
    • Tenga en cuenta si los desencadenadores automatizados se pueden aplicar como parte de las inversiones en ingeniería posteriores.

• Supervise el rendimiento de lectura y escritura de los datos de la aplicación en función de los requisitos de latencia P50/P99 y alinee con un modelo de capacidad de aplicación.

• El exceso de rendimiento debe controlarse correctamente por la plataforma de datos o la capa de aplicación y capturada por el modelo de mantenimiento para la representación operativa.

• Implemente el almacenamiento en caché para escenarios de datos "activos" para minimizar los tiempos de respuesta.

  • Aplique las directivas adecuadas para la expiración de la memoria caché y el mantenimiento interno para evitar el crecimiento de datos descontrolado.
    • Expire los elementos de caché cuando cambien los datos de respaldo.
    • Si la expiración de la memoria caché se basa estrictamente en el período de vida (TTL), es necesario comprender el impacto y la experiencia del cliente de atender datos obsoletos.

Variedad

• En consonancia con el principio de un diseño nativo de la nube y Azure, se recomienda priorizar los servicios administrados de Azure para reducir la complejidad operativa y de administración, y aprovechar las inversiones futuras en la plataforma de Microsoft.

• En consonancia con el principio de diseño de aplicaciones de arquitecturas de microservicios acopladas flexiblemente, permite que los servicios individuales usen distintos almacenes de datos y tecnologías de datos optimizadas para escenarios.

  • Identifique los tipos de estructura de datos que la aplicación controlará para escenarios de carga de trabajo específicos.
  • Evite crear una dependencia en un único almacén de datos monolítico.
    • Considere el patrón de diseño SAGA donde existen dependencias entre almacenes de datos.

• Valide que las funcionalidades necesarias están disponibles para las tecnologías de datos seleccionadas.

  • Asegúrese de la compatibilidad con los lenguajes necesarios y las funcionalidades del SDK. No todas las funcionalidades están disponibles para todos los lenguajes o SDK de la misma manera.

Veracidad

• Adopte un diseño de plataforma de datos de varias regiones y distribuya réplicas entre regiones para lograr la máxima confiabilidad, disponibilidad y rendimiento moviendo los datos más cerca de los puntos de conexión de la aplicación.

  • Distribuya réplicas de datos entre Availability Zones (AZ) dentro de una región (o use niveles de servicio con redundancia de zona) para maximizar la disponibilidad dentro de la región.

• Cuando los requisitos de coherencia lo permitan, use un diseño de plataforma de datos de escritura de varias regiones para maximizar la disponibilidad global y la confiabilidad.

  • Tenga en cuenta los requisitos empresariales para la resolución de conflictos cuando se cambia el mismo elemento de datos en dos réplicas de escritura independientes antes de que se pueda replicar cualquier cambio y, por tanto, crear un conflicto.
    • Use directivas estandarizadas de resolución de conflictos, como "El último gana", siempre que sea posible.
      • Si se requiere una estrategia personalizada con lógica personalizada, asegúrese de que se aplican prácticas de CI/CD DevOps para administrar la lógica personalizada.

• Pruebe y valide las funcionalidades de copia de seguridad y restauración, y las operaciones de conmutación por error a través de pruebas de caos dentro de los procesos de entrega continua.

• Ejecute pruebas comparativas de rendimiento para garantizar que los requisitos de rendimiento y rendimiento no se vean afectados por la inclusión de las funcionalidades de seguridad necesarias, como el cifrado.

  • Asegúrese de que los procesos de entrega continua consideren la posibilidad de realizar pruebas de carga con pruebas comparativas de rendimiento conocidas.

• Al aplicar el cifrado, se recomienda encarecidamente usar claves de cifrado administradas por el servicio como una manera de reducir la complejidad de la administración.

  • Si hay un requisito de seguridad específico para las claves administradas por el cliente, asegúrese de que se aplican los procedimientos de administración de claves adecuados para garantizar la disponibilidad, la copia de seguridad y la rotación de todas las claves consideradas.

Nota

Al integrar con una implementación organizativa más amplia, es fundamental que se aplique un enfoque centrado en la aplicación para el aprovisionamiento y el funcionamiento de los componentes de la plataforma de datos en un diseño de aplicación.

Más concretamente, para maximizar la confiabilidad, es fundamental que los componentes de la plataforma de datos individuales respondan adecuadamente al estado de la aplicación a través de acciones operativas que pueden incluir otros componentes de la aplicación. Por ejemplo, en un escenario en el que se necesitan recursos adicionales de la plataforma de datos, es probable que se requiera el escalado de la plataforma de datos junto con otros componentes de la aplicación según un modelo de capacidad, posiblemente mediante el aprovisionamiento de unidades de escalado adicionales. En última instancia, este enfoque se restringirá si hay una dependencia difícil de un equipo de operaciones centralizado para solucionar problemas relacionados con la plataforma de datos de forma aislada.

En última instancia, el uso de servicios de datos centralizados (es decir, DBaaS de TI central) presenta cuellos de botella operativos que dificultan significativamente la agilidad a través de una experiencia de administración en gran medida no contextualizada y deben evitarse en un contexto crítico para la misión o crítico para la empresa.

Referencias adicionales

En la Guía de arquitectura de Aplicación de Azure encontrará instrucciones adicionales sobre la plataforma de datos.

• Árbol de decisión del almacén de datos de Azure
• Criterios para elegir un almacén de datos
• Almacenes de datos no relacionales
• Almacenes de datos OLTP relacionales

Almacén de datos de escritura de varias regiones distribuido globalmente

Para dar cabida a las aspiraciones activas y activas distribuidas globalmente de un diseño de aplicación, se recomienda encarecidamente tener en cuenta una plataforma de datos de escritura distribuida de varias regiones, donde los cambios en réplicas que se pueden escribir independientes se sincronizan y combinan entre todas las réplicas, con resolución de conflictos cuando sea necesario.

Importante

Es posible que los microservicios no requieran un almacén de datos de escritura distribuido de varias regiones, por lo que se debe tener en cuenta el contexto arquitectónico y los requisitos empresariales de cada escenario de carga de trabajo.

Azure Cosmos DB proporciona un almacén de datos NoSQL distribuido globalmente y de alta disponibilidad, lo que ofrece escrituras en varias regiones y coherencia ajustable lista para usar. Por lo tanto, las consideraciones de diseño y las recomendaciones de esta sección se centrarán en el uso óptimo de Azure Cosmos DB.

Consideraciones de diseño

Azure Cosmos DB

• Azure Cosmos DB almacena datos en Contenedores, que son almacenes transaccionales indexados basados en filas diseñados para permitir lecturas y escrituras transaccionales rápidas con tiempos de respuesta en el orden de milisegundos.

• Azure Cosmos DB admite varias API diferentes con diferentes conjuntos de características, como SQL, Cassandra y MongoDB.

  • Azure Cosmos DB para NoSQL de primera entidad proporciona el conjunto de características más rico y suele ser la API donde las nuevas funcionalidades estarán disponibles en primer lugar.

• Azure Cosmos DB admite modos de conectividad directa y puerta de enlace, donde Direct facilita la conectividad a través de TCP a los nodos de réplica de Azure Cosmos DB de back-end para mejorar el rendimiento con menos saltos de red, mientras que la puerta de enlace proporciona conectividad HTTPS a los nodos de puerta de enlace de front-end.

  • El modo directo solo está disponible cuando se usa Azure Cosmos DB para NoSQL y actualmente solo se admite en plataformas del SDK de .NET y Java.

• Dentro de las regiones habilitadas para la zona de disponibilidad, Azure Cosmos DB ofrece compatibilidad con redundancia de zona de disponibilidad (AZ) para lograr alta disponibilidad y resistencia a errores zonales dentro de una región.

• Azure Cosmos DB mantiene cuatro réplicas de datos dentro de una sola región y, cuando la redundancia de zona de disponibilidad (AZ) está habilitada, Azure Cosmos DB garantiza que las réplicas de datos se colocan en varias AZ para protegerse frente a errores zonales.

  • El protocolo de consenso Paxos se aplica para lograr el cuórum entre réplicas dentro de una región.

• Una cuenta de Azure Cosmos DB se puede configurar fácilmente para replicar datos en varias regiones para mitigar el riesgo de que una sola región no esté disponible.

  • La replicación se puede configurar con escrituras de una sola región o escrituras de varias regiones.
    • Con las escrituras de una sola región, se usa una región principal "concentrador" para atender todas las escrituras y, si esta región "concentrador" deja de estar disponible, se debe producir una operación de conmutación por error para promover otra región como grabable.
    • Con las escrituras en varias regiones, las aplicaciones pueden escribir en cualquier región de implementación configurada, que replicará los cambios entre todas las demás regiones. Si una región no está disponible, las regiones restantes se usarán para atender el tráfico de escritura.

• En una configuración de escritura en varias regiones, pueden producirse conflictos de actualización (inserción, reemplazo, eliminación) en los que los escritores actualizan simultáneamente el mismo elemento en varias regiones.

• Azure Cosmos DB proporciona dos directivas de resolución de conflictos, que se pueden aplicar para abordar automáticamente los conflictos.

  • Last Write Wins (LWW) aplica un protocolo de reloj de sincronización de hora mediante una propiedad timestamp _ts definida por el sistema como ruta de acceso de resolución de conflictos. Si de un conflicto, el elemento con el valor más alto para la ruta de acceso de resolución de conflictos se convierte en el ganador y, si varios elementos tienen el mismo valor numérico, el sistema selecciona un ganador para que todas las regiones puedan converger con la misma versión del elemento confirmado.
    • Con los conflictos de eliminación, la versión eliminada siempre gana por encima de los conflictos de inserción o reemplazo, independientemente del valor de ruta de acceso de resolución de conflictos.
    • Últimos casos de escritura correcta es la directiva de resolución de conflictos predeterminada
    • Cuando se usa Azure Cosmos DB para NoSQL, se puede usar una propiedad numérica personalizada, como una definición de marca de tiempo personalizada, para la resolución de conflictos.
  • Las directivas de resolución personalizadas permiten que la semántica definida por la aplicación concilie los conflictos mediante un procedimiento almacenado de combinación registrado que se invoca automáticamente cuando se detectan conflictos.
    • El sistema garantiza exactamente una vez la ejecución de un procedimiento de combinación como parte del protocolo de confirmación.
    • Una directiva de resolución de conflictos personalizada solo está disponible con Azure Cosmos DB para NoSQL y solo se puede establecer en el momento de creación del contenedor.

• En una configuración de escritura de varias regiones, hay una dependencia en una sola región de "concentrador" de Azure Cosmos DB para realizar todas las resoluciones de conflictos, con el protocolo de consenso Paxos aplicado para lograr el cuórum entre réplicas dentro de la región central.

  • La plataforma proporciona un búfer de mensajes para los conflictos de escritura dentro de la región central para cargar el nivel de carga y proporcionar redundancia para errores transitorios.
    • El búfer es capaz de almacenar unos minutos de actualizaciones de escritura que requieren consenso.

La dirección estratégica de la plataforma Azure Cosmos DB es quitar esta dependencia de una sola región para la resolución de conflictos en una configuración de escritura de varias regiones, utilizando un enfoque paxos de 2 fases para alcanzar el cuórum a nivel global y dentro de una región.

• La región principal "hub" viene determinada por la primera región en la que se configura Azure Cosmos DB.

  • Un orden de prioridad se configura para regiones de implementación satélite adicionales con fines de conmutación por error.

• El modelo de datos y la creación de particiones entre particiones lógicas y físicas desempeñan un papel importante para lograr un rendimiento y una disponibilidad óptimos.

• Cuando se implementa con una sola región de escritura, Azure Cosmos DB se puede configurar para la conmutación automática por error en función de una prioridad de conmutación por error definida teniendo en cuenta todas las réplicas de región de lectura.

• El RTO proporcionado por la plataforma Azure Cosmos DB es de aproximadamente 10 a 15 minutos, capturando el tiempo transcurrido para realizar una conmutación por error regional del servicio Azure Cosmos DB si un desastre catastrófico afecta a la región del centro.

  • Este RTO también es relevante en un contexto de escritura de varias regiones dada la dependencia de una sola región "concentrador" para la resolución de conflictos.
    • Si la región "hub" deja de estar disponible, se producirá un error en las escrituras realizadas en otras regiones después de que se rellene el búfer de mensajes, ya que la resolución de conflictos no podrá producirse hasta que se conmute por error el servicio y se establezca una nueva región central.

La dirección estratégica de la plataforma Azure Cosmos DB es reducir el RTO a aproximadamente 5 minutos al permitir conmutaciones por error de nivel de partición.

• Los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO) se pueden configurar a través de niveles de coherencia, con un equilibrio entre la durabilidad y el rendimiento de los datos.

  • Azure Cosmos DB proporciona un RTO mínimo de 0 para un nivel de coherencia relajado con escrituras de varias regiones o un RPO de 0 para una coherencia sólida con una región de escritura única.

• Azure Cosmos DB ofrece un Acuerdo de Nivel de Servicio del 99,999 % para la disponibilidad de lectura y escritura para las cuentas de base de datos configuradas con varias regiones de Azure como grabables.

  • El Acuerdo de Nivel de Servicio se representa mediante el porcentaje de tiempo de actividad mensual, que se calcula como 100% - Tasa media de errores.
  • La tasa de errores promedio se define como la suma de las tasas de error de cada hora del mes de facturación dividida por el número total de horas del mes de facturación, donde la tasa de errores es el número total de solicitudes con error divididas por total de solicitudes durante un intervalo determinado de una hora.

• Azure Cosmos DB ofrece un Acuerdo de Nivel de Servicio del 99,99 % para el rendimiento, la coherencia, la disponibilidad y la latencia de las cuentas de base de datos cuyo ámbito es una sola región de Azure cuando se configura con cualquiera de los cinco niveles de coherencia.

  • Un Acuerdo de Nivel de Servicio del 99,99 % también se aplica a las cuentas de base de datos que abarcan varias regiones de Azure configuradas con cualquiera de los cuatro niveles de coherencia relajados.

• Hay dos tipos de rendimiento que se pueden aprovisionar en Azure Cosmos DB, el estándar y el escalado automático, que se miden mediante unidades de solicitud por segundo (RU/s).

  • El rendimiento estándar asigna los recursos necesarios para garantizar un valor de RU/s especificado.
    • El estándar se factura cada hora para el rendimiento aprovisionado.
  • El escalado automático define un valor de rendimiento máximo y Azure Cosmos DB se escalará o reducirá verticalmente automáticamente en función de la carga de la aplicación, entre el valor de rendimiento máximo y un mínimo del 10 % del valor máximo de rendimiento.
    • El escalado automático se factura cada hora por el rendimiento máximo consumido.

• El rendimiento aprovisionado estático con una carga de trabajo variable puede producir errores de limitación, lo que afectará a la disponibilidad de la aplicación percibido.

  • El escalado automático protege contra los errores de limitación al permitir que Azure Cosmos DB se escale verticalmente según sea necesario, a la vez que mantiene la protección de costos al reducir verticalmente cuando se reduce la carga.

• Cuando Azure Cosmos DB se replica en varias regiones, las unidades de solicitud (RU) aprovisionadas se facturan por región.

• Hay una diferencia de costos significativa entre una configuración de escritura en varias regiones y escritura de una sola región que, en muchos casos, puede suponer un costo prohibitivo de la plataforma de datos de Azure Cosmos DB multimaestro.

Lectura y escritura de una sola región	Escritura de una sola región: lectura de región dual	Lectura y escritura en dos regiones
1 RU	2 RU	4 RU

La diferencia entre la escritura de una sola región y la escritura en varias regiones es realmente menor que la relación de 1:2 reflejada en la tabla anterior. En concreto, hay un cargo de transferencia de datos entre regiones asociado a las actualizaciones de escritura en una configuración de escritura única, que no se captura dentro de los costos de RU como con la configuración de escritura en varias regiones.

• El almacenamiento consumido se factura como una tarifa plana para la cantidad total de almacenamiento (GB) consumida para hospedar datos e índices durante una hora determinada.

• Session es el valor predeterminado y el nivel de coherencia más usado, ya que los datos se reciben en el mismo orden que las escrituras.

• Azure Cosmos DB admite la autenticación a través de una identidad de Microsoft Entra o claves y tokens de recursos de Azure Cosmos DB, que proporcionan funcionalidades superpuestas.

Funcionalidades de

• Es posible deshabilitar las operaciones de administración de recursos mediante claves o tokens de recursos para limitar las claves y los tokens de recursos solo a las operaciones de datos, lo que permite el control de acceso a recursos específico mediante Microsoft Entra control de acceso basado en rol (RBAC).

  • La restricción del acceso del plano de control a través de claves o tokens de recursos deshabilitará las operaciones del plano de control para los clientes que usan los SDK de Azure Cosmos DB y, por lo tanto, se deben evaluar y probar exhaustivamente.
  • La disableKeyBasedMetadataWriteAccess configuración se puede configurar a través de definiciones de IaC de plantilla de ARM o a través de un Azure Policy integrado.

• Microsoft Entra compatibilidad con RBAC en Azure Cosmos DB se aplica a las operaciones de administración del plano de control de recursos y cuentas.

  • Los administradores de aplicaciones pueden crear asignaciones de roles para usuarios, grupos, entidades de servicio o identidades administradas para conceder o denegar el acceso a recursos y operaciones en recursos de Azure Cosmos DB.
  • Hay varios roles RBAC integrados disponibles para la asignación de roles y los roles RBAC personalizados también se pueden usar para formar combinaciones de privilegios específicas.
    • El Lector de cuentas de Cosmos DB permite el acceso de solo lectura al recurso de Azure Cosmos DB.
    • Colaborador de la cuenta de DocumentDB permite la administración de cuentas de Azure Cosmos DB, incluidas las claves y las asignaciones de roles, pero no habilita el acceso al plano de datos.
    • Operador de Cosmos DB, que es similar al colaborador de la cuenta de DocumentDB, pero no proporciona la capacidad de administrar claves o asignaciones de roles.

• Los recursos de Azure Cosmos DB (cuentas, bases de datos y contenedores) se pueden proteger frente a modificaciones o eliminaciones incorrectas mediante bloqueos de recursos.

  • Los bloqueos de recursos se pueden establecer en el nivel de cuenta, base de datos o contenedor.
  • Todos los recursos secundarios heredarán un bloqueo de recursos establecido en en un recurso. Por ejemplo, todos los contenedores y bases de datos de la cuenta de Azure Cosmos DB heredarán un conjunto de bloqueo de recursos en la cuenta.
  • Los bloqueos de recursos solo se aplican a las operaciones del plano de control y no impiden las operaciones del plano de datos, como crear, cambiar o eliminar datos.
  • Si el acceso al plano de control no está restringido con disableKeyBasedMetadataWriteAccess, los clientes podrán realizar operaciones del plano de control mediante claves de cuenta.

• La fuente de cambios de Azure Cosmos DB proporciona una fuente ordenada por el tiempo de los cambios en los datos de un contenedor de Azure Cosmos DB.

  • La fuente de cambios solo incluye operaciones de inserción y actualización en el contenedor de Azure Cosmos DB de origen; no incluye eliminaciones.

• La fuente de cambios se puede usar para mantener un almacén de datos independiente del contenedor principal utilizado por la aplicación, con actualizaciones continuas en el almacén de datos de destino alimentado por la fuente de cambios del contenedor de origen.

  • La fuente de cambios se puede usar para rellenar un almacén secundario para la redundancia adicional de la plataforma de datos o para escenarios analíticos posteriores.

• Si las operaciones de eliminación afectan de forma rutinaria a los datos dentro del contenedor de origen, el almacén alimentado por la fuente de cambios será inexacto y no será relectivo de los datos eliminados.

  • Se puede implementar un patrón de eliminación temporal para que los registros de datos se incluyan en la fuente de cambios.
    • En lugar de eliminar explícitamente los registros de datos, los registros de datos se actualizan estableciendo una marca (por ejemplo IsDeleted, ) para indicar que el elemento se considera eliminado.
    • Cualquier almacén de datos de destino alimentado por la fuente de cambios deberá detectar y procesar elementos con una marca eliminada establecida en True; en lugar de almacenar registros de datos eliminados temporalmente, será necesario eliminar la versión existente del registro de datos en el almacén de destino.
  • Normalmente, se usa un breve período de vida (TTL) con el patrón de eliminación temporal para que Azure Cosmos DB elimine automáticamente los datos expirados, pero solo después de que se refleje en la fuente de cambios con la marca eliminada establecida en True.
    • Realiza la intención de eliminación original, mientras que también propaga la eliminación a través de la fuente de cambios.

• Azure Cosmos DB se puede configurar como un almacén analítico, que aplica un formato de columna para consultas analíticas optimizadas para abordar los desafíos de complejidad y latencia que se producen con las canalizaciones ETL tradicionales.

• Azure Cosmos DB realiza automáticamente una copia de seguridad de los datos a intervalos regulares sin afectar al rendimiento o la disponibilidad, y sin consumir RU/s.

• Azure Cosmos DB se puede configurar según dos modos de copia de seguridad distintos.

  • Periódica es el modo de copia de seguridad predeterminado para todas las cuentas, donde las copias de seguridad se realizan a intervalos periódicos y los datos se restauran mediante la creación de una solicitud con el equipo de soporte técnico.
    • El período de retención de copia de seguridad periódico predeterminado es de ocho horas y el intervalo de copia de seguridad predeterminado es de cuatro horas, lo que significa que solo se almacenan las dos copias de seguridad más recientes de forma predeterminada.
    • El intervalo de copia de seguridad y el período de retención se pueden configurar dentro de la cuenta.
      • El período de retención máximo se extiende a un mes con un intervalo de copia de seguridad mínimo de una hora.
      • Se requiere una asignación de roles al rol de lector de cuentas de Azure "Cosmos DB" para configurar la redundancia del almacenamiento de copia de seguridad.
    • Se incluyen dos copias de seguridad sin costo adicional, pero las copias de seguridad adicionales incurren en costos adicionales.
    • De forma predeterminada, las copias de seguridad periódicas se almacenan en Geo-Redundant Storage (GRS) independientes que no son accesibles directamente.
      • El almacenamiento de copia de seguridad existe dentro de la región principal "hub" y se replica en la región emparejada a través de la replicación de almacenamiento subyacente.
      • La configuración de redundancia de la cuenta de almacenamiento de copia de seguridad subyacente se puede configurar en Almacenamiento con redundancia de zona o Locally-Redundant Storage.
    • La realización de una operación de restauración requiere una solicitud de soporte técnico , ya que los clientes no pueden realizar directamente una restauración.
      • Antes de abrir una incidencia de soporte técnico, el período de retención de copia de seguridad debe aumentarse a al menos siete días en un plazo de ocho horas después del evento de pérdida de datos.
    • Una operación de restauración crea una nueva cuenta de Azure Cosmos DB donde se recuperan los datos.
      • No se puede usar una cuenta de Azure Cosmos DB existente para restaurar
      • De forma predeterminada, se usará una nueva cuenta de Azure Cosmos DB denominada <Azure_Cosmos_account_original_name>-restored<n> .
        • Este nombre se puede ajustar, por ejemplo, reutilizando el nombre existente si se eliminó la cuenta original.
    • Si el rendimiento se aprovisiona en el nivel de base de datos, la copia de seguridad y la restauración se realizarán en el nivel de base de datos.
      • No es posible seleccionar un subconjunto de contenedores para restaurar.
  • El modo de copia de seguridad continua permite una restauración a cualquier momento en los últimos 30 días.
    • Las operaciones de restauración se pueden realizar para volver a un momento dado específico (PITR) con una granularidad de un segundo.
    • La ventana disponible para las operaciones de restauración es de hasta 30 días.
      • También es posible restaurar al estado de creación de instancias de recursos.
    • Las copias de seguridad continuas se realizan dentro de cada región de Azure donde existe la cuenta de Azure Cosmos DB.
      • Las copias de seguridad continuas se almacenan en la misma región de Azure que cada réplica de Azure Cosmos DB, mediante Locally-Redundant Storage (LRS) o almacenamiento con redundancia de zona (ZRS) dentro de las regiones que admiten Availability Zones.
    • Una restauración de autoservicio se puede realizar mediante los artefactos de Azure Portal o IaC, como las plantillas de ARM.
    • Hay varias limitaciones con la copia de seguridad continua.
      • El modo de copia de seguridad continua no está disponible actualmente en una configuración de escritura en varias regiones.
      • Solo Azure Cosmos DB para NoSQL y Azure Cosmos DB para MongoDB se pueden configurar para la copia de seguridad continua en este momento.
      • Si un contenedor tiene TTL configurado, los datos restaurados que han superado su TTL se pueden eliminar inmediatamente.
    • Una operación de restauración crea una nueva cuenta de Azure Cosmos DB para la restauración a un momento dado.
    • Hay un costo de almacenamiento adicional para las copias de seguridad continuas y las operaciones de restauración.

• Las cuentas de Azure Cosmos DB existentes se pueden migrar de Periódica a Continua, pero no de Continua a Periódica; la migración es unidireccional y no reversible.

• Cada copia de seguridad de Azure Cosmos DB se compone de los propios datos y los detalles de configuración para el rendimiento aprovisionado, las directivas de indexación, las regiones de implementación y la configuración de TTL del contenedor.

  • Las copias de seguridad no contienen la configuración del firewall, las listas de control de acceso de red virtual, la configuración del punto de conexión privado, la configuración de coherencia (se restaura una cuenta con coherencia de sesión), los procedimientos almacenados, los desencadenadores, las UDF o la configuración de varias regiones.
    • Los clientes son responsables de volver a implementar las funcionalidades y las opciones de configuración. No se restauran a través de la copia de seguridad de Azure Cosmos DB.
  • Azure Synapse Vincular datos del almacén analítico tampoco se incluye en las copias de seguridad de Azure Cosmos DB.

• Es posible implementar una funcionalidad de copia de seguridad y restauración personalizada para escenarios en los que los enfoques periódicos y continuos no son una buena opción.

  • Un enfoque personalizado presenta costos significativos y sobrecarga administrativa adicional, que se debe entender y evaluar cuidadosamente.
    • Los escenarios de restauración comunes deben modelarse, como daños o eliminación de una cuenta, una base de datos, un contenedor, en un elemento de datos.
    • Se deben implementar procedimientos de limpieza para evitar la expansión de las copias de seguridad.
  • Se puede usar Azure Storage o una tecnología de datos alternativa, como un contenedor alternativo de Azure Cosmos DB.
    • Azure Storage y Azure Cosmos DB proporcionan integraciones nativas con servicios de Azure, como Azure Functions y Azure Data Factory.

• La documentación de Azure Cosmos DB indica dos posibles opciones para implementar copias de seguridad personalizadas.

  • Fuente de cambios de Azure Cosmos DB para escribir datos en una instalación de almacenamiento independiente.
    • Una función de Azure o un proceso de aplicación equivalente usa el procesador de fuente de cambios para enlazar a la fuente de cambios y procesar elementos en el almacenamiento.
  • Las copias de seguridad personalizadas continuas o periódicas (por lotes) se pueden implementar mediante la fuente de cambios.
  • La fuente de cambios de Azure Cosmos DB aún no refleja las eliminaciones, por lo que se debe aplicar un patrón de eliminación temporal mediante una propiedad booleana y TTL.
    • Este patrón no será necesario cuando la fuente de cambios proporcione actualizaciones de fidelidad completa.
  • Azure Data Factory Connector para Azure Cosmos DB (conectores de Api de Azure Cosmos DB para NoSQL o MongoDB) para copiar datos.
    • Azure Data Factory (ADF) admite la ejecución manual y programación, la ventana de saltos de tamaño constante y los desencadenadores basados en eventos.
      • Proporciona compatibilidad con Storage y Event Grid.
    • ADF es principalmente adecuado para implementaciones de copia de seguridad personalizadas periódicas debido a su orquestación orientada a lotes.
      • Es menos adecuado para las implementaciones de copia de seguridad continuas con eventos frecuentes debido a la sobrecarga de ejecución de orquestación.
    • ADF admite Azure Private Link para escenarios de seguridad de red elevados

Azure Cosmos DB se usa dentro del diseño de muchos servicios de Azure, por lo que una interrupción regional significativa de Azure Cosmos DB tendrá un efecto en cascada en varios servicios de Azure dentro de esa región. El impacto preciso en un servicio determinado dependerá en gran medida de cómo el diseño del servicio subyacente use Azure Cosmos DB.

Recomendaciones de diseño

Azure Cosmos DB

• Use Azure Cosmos DB como plataforma de datos principal donde se permitan los requisitos.

• Para escenarios de carga de trabajo críticos, configure Azure Cosmos DB con una réplica de escritura dentro de cada región de implementación para reducir la latencia y proporcionar una redundancia máxima.

  • Configure la aplicación para priorizar el uso de la réplica local de Azure Cosmos DB para escrituras y lecturas para optimizar la carga de la aplicación, el rendimiento y el consumo de RU/s regionales.
  • La configuración de escritura en varias regiones conlleva un costo significativo y solo se debe priorizar para escenarios de carga de trabajo que requieran máxima confiabilidad.

• Para escenarios de carga de trabajo menos críticos, priorice el uso de la configuración de escritura en una sola región (cuando se usa Availability Zones) con réplicas de lectura distribuidas globalmente, ya que esto ofrece un alto nivel de confiabilidad de la plataforma de datos (acuerdo de nivel de servicio del 99,999 % para lectura y 99,995 % para operaciones de escritura) a un precio más atractivo.

  • Configure la aplicación para que use la réplica de lectura local de Azure Cosmos DB para optimizar el rendimiento de lectura.

• Seleccione una región de implementación "hub" óptima en la que se producirá la resolución de conflictos en una configuración de escritura en varias regiones y todas las escrituras se realizarán en una configuración de escritura de una sola región.

  • Considere la distancia en relación con otras regiones de implementación y la latencia asociada al seleccionar una región primaria y las funcionalidades necesarias, como Availability Zones compatibilidad.

• Configure Azure Cosmos DB con redundancia de zona de disponibilidad (AZ) en todas las regiones de implementación con compatibilidad con AZ para garantizar la resistencia a errores zonales dentro de una región.

• Use Azure Cosmos DB para NoSQL, ya que ofrece el conjunto de características más completo, especialmente cuando se trata del ajuste del rendimiento.

  • Las API alternativas se deben tener en cuenta principalmente para escenarios de migración o compatibilidad.
    • Al usar API alternativas, compruebe que las funcionalidades necesarias están disponibles con el lenguaje y el SDK seleccionados para garantizar una configuración y un rendimiento óptimos.

• Use el modo de conexión directa para optimizar el rendimiento de la red a través de la conectividad TCP directa a los nodos de Azure Cosmos DB de back-end, con un número reducido de "saltos" de red.

El Acuerdo de Nivel de Servicio de Azure Cosmos DB se calcula al calcular el promedio de solicitudes con errores, lo que puede no alinearse directamente con un presupuesto de errores del nivel de confiabilidad del 99,999 %. Al diseñar para un SLO del 99,999 %, es fundamental planear la falta de disponibilidad de escritura regional y de varias regiones de Azure Cosmos DB, lo que garantiza que se coloque una tecnología de almacenamiento de reserva si se produce un error, como una cola de mensajes persistente para la reproducción posterior.

• Defina una estrategia de creación de particiones entre particiones lógicas y físicas para optimizar la distribución de datos según el modelo de datos.

  • Minimización de consultas con particiones cruzadas.
  • Pruebe y valide de forma iterativa la estrategia de creación de particiones para garantizar un rendimiento óptimo.

• Seleccione una clave de partición óptima.

  • La clave de partición no se puede cambiar una vez creada dentro de la colección.
  • La clave de partición debe ser un valor de propiedad que no cambia.
  • Seleccione una clave de partición que tenga una cardinalidad alta, con una amplia gama de valores posibles.
  • La clave de partición debe distribuir el consumo de RU y el almacenamiento de datos uniformemente en todas las particiones lógicas para garantizar incluso el consumo de RU y la distribución de almacenamiento entre particiones físicas.
  • Ejecute consultas de lectura en la columna con particiones para reducir el consumo de RU y la latencia.

• La indexación también es fundamental para el rendimiento, por lo que se garantiza que las exclusiones de índices se usen para reducir los requisitos de RU/s y almacenamiento.

  • Indexe únicamente los campos necesarios para filtrar dentro de las consultas; índices de diseño para los predicados más usados.

• Aproveche las funcionalidades integradas de control de errores, reintento y confiabilidad más amplia del SDK de Azure Cosmos DB.

  • Implemente la lógica de reintento en el SDK en los clientes.

• Use claves de cifrado administradas por el servicio para reducir la complejidad de la administración.

  • Si hay un requisito de seguridad específico para las claves administradas por el cliente, asegúrese de que se aplican los procedimientos de administración de claves adecuados, como la copia de seguridad y la rotación.

• Deshabilite el acceso de escritura de metadatos basado en claves de Azure Cosmos DB aplicando el Azure Policy integrado.

• Habilite Azure Monitor para recopilar métricas clave y registros de diagnóstico, como el rendimiento aprovisionado (RU/s).

  • Enrutar los datos operativos de Azure Monitor a un área de trabajo de Log Analytics dedicada a Azure Cosmos DB y otros recursos globales dentro del diseño de la aplicación.
  • Use métricas de Azure Monitor para determinar si los patrones de tráfico de aplicaciones son adecuados para el escalado automático.

• Evalúe los patrones de tráfico de la aplicación para seleccionar una opción óptima para los tipos de rendimiento aprovisionados.

  • Considere la posibilidad de escalar automáticamente el rendimiento aprovisionado para redistribuir automáticamente la demanda de cargas de trabajo de nivelado.

• Evalúe las sugerencias de rendimiento de Microsoft para Que Azure Cosmos DB optimice la configuración del lado cliente y del lado servidor para mejorar la latencia y el rendimiento.

• Al usar AKS como plataforma de proceso: para cargas de trabajo con un uso intensivo de consultas, seleccione una SKU de nodo de AKS que tenga habilitadas las redes aceleradas para reducir la latencia y las fluctuaciones de CPU.

• En el caso de las implementaciones de una sola región de escritura, se recomienda encarecidamente configurar Azure Cosmos DB para la conmutación automática por error.

• Nivel de carga mediante el uso de mensajería asincrónica sin bloqueo dentro de los flujos del sistema, que escriben actualizaciones en Azure Cosmos DB.

  • Tenga en cuenta patrones como la segregación de responsabilidades de comandos y consultas y event sourcing.

• Configure la cuenta de Azure Cosmos DB para las copias de seguridad continuas para obtener una granularidad fina de los puntos de recuperación en los últimos 30 días.

  • Considere el uso de copias de seguridad de Azure Cosmos DB en escenarios en los que los datos contenidos o la cuenta de Azure Cosmos DB se eliminan o dañan.
  • Evite el uso de un enfoque de copia de seguridad personalizado a menos que sea absolutamente necesario.

• Se recomienda encarecidamente practicar procedimientos de recuperación en recursos y datos que no son de producción, como parte de la preparación estándar de la operación de continuidad empresarial.

• Defina artefactos de IaC para volver a establecer las opciones de configuración y las funcionalidades de una restauración de copia de seguridad de Azure Cosmos DB.

• Evalúe y aplique la guía de control de línea de base de seguridad de Azure para copia de seguridad y recuperación de Azure Cosmos DB.

  • BR-1: Garantía de copias de seguridad automáticas periódicas
  • BR-3: Validación de todas las copias de seguridad, incluidas las claves administradas por el cliente
  • BR-4, Mitigación del riesgo de pérdida de claves

• Para cargas de trabajo analíticas que requieren disponibilidad en varias regiones, use el almacén analítico de Azure Cosmos DB, que aplica un formato de columna para consultas analíticas optimizadas.

Tecnologías de datos relacionales

En escenarios con un modelo de datos altamente relacional o dependencias en tecnologías relacionales existentes, es posible que el uso de Azure Cosmos DB en una configuración de escritura en varias regiones no sea aplicable directamente. En tales casos, es fundamental que las tecnologías relacionales usadas estén diseñadas y configuradas para mantener las aspiraciones activas-activas de varias regiones de un diseño de aplicación.

Azure proporciona muchas plataformas de datos relacionales administradas, como Azure SQL Database y Azure Database para soluciones relacionales comunes del sistema operativo, como MySQL, PostgreSQL y MariaDB. Por lo tanto, las consideraciones y recomendaciones de diseño de esta sección se centrarán en el uso óptimo de Azure SQL Database y los tipos de SOS de Azure Database para maximizar la confiabilidad y la disponibilidad global.

Consideraciones de diseño

• Aunque las tecnologías de datos relacionales se pueden configurar para escalar fácilmente las operaciones de lectura, las escrituras normalmente se limitan a pasar por una única instancia principal, lo que impone una restricción significativa en la escalabilidad y el rendimiento.

• El particionamiento se puede aplicar para distribuir los datos y el procesamiento en varias bases de datos estructuradas idénticas, particionando bases de datos horizontalmente para navegar por las restricciones de la plataforma.

  • Por ejemplo, el particionamiento se aplica a menudo en plataformas SaaS multiinquilino para aislar grupos de inquilinos en construcciones de plataforma de datos distintivas.

Azure SQL Database

• Azure SQL Database proporciona un motor de base de datos totalmente administrado que siempre se ejecuta en la versión estable más reciente del motor de base de datos de SQL Server y del sistema operativo subyacente.

  • Proporciona características inteligentes, como el ajuste del rendimiento, la supervisión de amenazas y las evaluaciones de vulnerabilidades.

• Azure SQL Database proporciona alta disponibilidad regional integrada y replicación geográfica llave en mano para distribuir réplicas de lectura entre regiones de Azure.

  • Con la replicación geográfica, las réplicas de base de datos secundarias permanecen de solo lectura hasta que se inicia una conmutación por error.
  • Se admiten hasta cuatro secundarias en las mismas regiones o en regiones diferentes.
  • Las réplicas secundarias también se pueden usar para el acceso de consulta de solo lectura para optimizar el rendimiento de lectura.
  • La conmutación por error se debe iniciar manualmente, pero se puede encapsular en procedimientos operativos automatizados.

• Azure SQL Database proporciona grupos de conmutación por error automática, que replica las bases de datos en un servidor secundario y permite una conmutación por error transparente si se produce un error.

  • Los grupos de conmutación por error automática admiten la replicación geográfica de todas las bases de datos en el grupo solo a una instancia o un servidor secundario en otra región.
  • Los grupos de conmutación por error automática no se admiten actualmente en el nivel de servicio Hiperescala.
  • Las bases de datos secundarias se pueden usar para descargar el tráfico de lectura.

• Las réplicas de base de datos de nivel de servicio Premium o Crítico para la empresa se pueden distribuir entre Availability Zones sin costo adicional.

  • El anillo de control también se duplica en varias zonas como tres anillos de puerta de enlace (GW).
    • El enrutamiento a un anillo de puerta de enlace específico se controla mediante Azure Traffic Manager.
  • Cuando se usa el nivel crítico para la empresa, la configuración de redundancia de zona solo está disponible cuando se selecciona el hardware de proceso Gen5.

• Azure SQL Database ofrece un Acuerdo de Nivel de Servicio de disponibilidad previsto del 99,99 % en todos sus niveles de servicio, pero proporciona un Acuerdo de Nivel de Servicio del 99,995 % superior para los niveles Crítico para la empresa o Premium en las regiones que admiten zonas de disponibilidad.

  • Azure SQL Los niveles Crítico para la empresa o Premium de base de datos no configurados para las implementaciones con redundancia de zona tienen un Acuerdo de Nivel de Servicio de disponibilidad del 99,99 %.

• Cuando se configura con replicación geográfica, el nivel Crítico para la empresa base de datos de Azure SQL proporciona un objetivo de tiempo de recuperación (RTO) de 30 segundos durante el 100 % de las horas implementadas.

• Cuando se configura con replicación geográfica, el nivel Azure SQL Database Crítico para la empresa tiene un objetivo de punto de recuperación (RPO) de 5 segundos durante el 100 % de las horas implementadas.

• Azure SQL nivel hiperescala de base de datos, cuando se configura con al menos dos réplicas, tiene un Acuerdo de Nivel de Servicio de disponibilidad del 99,99 %.

• Los costos de proceso asociados a Azure SQL Database se pueden reducir mediante un descuento por reserva.

  • No es posible aplicar capacidad reservada para bases de datos basadas en DTU.

• La restauración a un momento dado se puede usar para devolver una base de datos y datos contenidos a un momento dado anterior.

• La restauración geográfica se puede usar para recuperar una base de datos a partir de una copia de seguridad con redundancia geográfica.

Azure Database For PostgreSQL

• Azure Database For PostgreSQL se ofrece en tres opciones de implementación diferentes:

  • Servidor único, Acuerdo de Nivel de Servicio 99,99 %
  • Servidor flexible, que ofrece redundancia de zona de disponibilidad, Acuerdo de Nivel de Servicio del 99,99 %
  • Hiperescala (Citus), SLA 99,95 % cuando está habilitado el modo de alta disponibilidad.

• Hiperescala (Citus) proporciona escalabilidad dinámica mediante particionamiento sin cambios en la aplicación.

  • La distribución de filas de tabla entre varios servidores PostgreSQL es clave para garantizar consultas escalables en Hiperescala (Citus).
  • Varios nodos pueden contener colectivamente más datos que una base de datos tradicional y, en muchos casos, pueden usar CPU de trabajo en paralelo para optimizar los costos.

• El escalado automático se puede configurar mediante la automatización de runbooks para garantizar la elasticidad en respuesta a los patrones de tráfico cambiantes.

• El servidor flexible proporciona eficiencias de costos para cargas de trabajo que no son de producción a través de la capacidad de detener o iniciar el servidor, y un nivel de proceso ampliable adecuado para cargas de trabajo que no requieren capacidad de proceso continua.

• No hay ningún cargo adicional por el almacenamiento de copia de seguridad hasta el 100 % del almacenamiento total del servidor aprovisionado.

  • El consumo adicional del almacenamiento de copia de seguridad se cobra según GB/mes consumidos.

• Los costos de proceso asociados a Azure Database for PostgreSQL se pueden reducir mediante un descuento de reserva de servidor único o un descuento de reserva de Hiperescala (Citus).

Recomendaciones de diseño

• Considere la posibilidad de particionar para crear particiones de bases de datos relacionales basadas en diferentes contextos de datos y aplicaciones, lo que ayuda a navegar por las restricciones de la plataforma, maximizar la escalabilidad y la disponibilidad y el aislamiento de errores.

  • Esta recomendación es especialmente frecuente cuando el diseño de la aplicación considera tres o más regiones de Azure, ya que las restricciones de tecnología relacional pueden dificultar significativamente las plataformas de datos distribuidas globalmente.
  • El particionamiento no es adecuado para todos los escenarios de aplicación, por lo que se requiere una evaluación contextualizada.

• Dé prioridad al uso de Azure SQL Database donde existen requisitos relacionales debido a su madurez en la plataforma Azure y a una amplia gama de funcionalidades de confiabilidad.

Azure SQL Database

• Use el nivel de servicio Business-Critical para maximizar la confiabilidad y la disponibilidad, incluido el acceso a las funcionalidades de resistencia críticas.

• Use el modelo de consumo basado en núcleo virtual para facilitar la selección independiente de los recursos de proceso y almacenamiento, adaptados a los requisitos de volumen y rendimiento de la carga de trabajo.

  • Asegúrese de que se aplica un modelo de capacidad definido para informar a los requisitos de recursos de proceso y almacenamiento.
    • Considere la posibilidad de capacidad reservada para proporcionar posibles optimizaciones de costos.

• Configure el modelo de implementación de Zone-Redundant para distribuir Crítico para la empresa réplicas de base de datos dentro de la misma región en Availability Zones.

• Use la replicación geográfica activa para implementar réplicas legibles en todas las regiones de implementación (hasta cuatro).

• Use grupos de conmutación por error automática para proporcionar conmutación por error transparente a una región secundaria, con replicación geográfica aplicada para proporcionar replicación a regiones de implementación adicionales para la optimización de lectura y la redundancia de la base de datos.

  • En escenarios de aplicación limitados a solo dos regiones de implementación, se debe priorizar el uso de grupos de conmutación por error automática.

• Considere la posibilidad de que los desencadenadores operativos automatizados, en función de las alertas alineadas con el modelo de estado de la aplicación, realicen conmutaciones por error a instancias con replicación geográfica si un error afecta a la principal y secundaria dentro del grupo de conmutación por error automática.

Importante

En el caso de las aplicaciones que consideran más de cuatro regiones de implementación, se debe tener en cuenta en serio el particionamiento con ámbito de aplicación o la refactorización de la aplicación para admitir tecnologías de escritura de varias regiones, como Azure Cosmos DB. Sin embargo, si esto no es factible en el escenario de carga de trabajo de la aplicación, se recomienda elevar una región dentro de una sola geografía a un estado principal que abarca una instancia con replicación geográfica a acceso de lectura distribuido de forma más uniforme.

• Configure la aplicación para consultar las instancias de réplica para las consultas de lectura para optimizar el rendimiento de lectura.

• Use Azure Monitor y Azure SQL Analytics para obtener información operativa casi en tiempo real en Azure SQL BASE de datos para la detección de incidentes de confiabilidad.

• Use Azure Monitor para evaluar el uso de todas las bases de datos para determinar si se han dimensionado correctamente.

  • Asegúrese de que las canalizaciones de CD consideran la posibilidad de realizar pruebas de carga en niveles de carga representativos para validar el comportamiento adecuado de la plataforma de datos.

• Calcule una métrica de estado para que los componentes de base de datos observen el estado relativo a los requisitos empresariales y el uso de recursos, mediante la supervisión y las alertas para impulsar la acción operativa automatizada cuando corresponda.

  • Asegúrese de que las métricas clave de rendimiento de las consultas se incorporan para que se pueda realizar una acción rápida cuando se produzca una degradación del servicio.

• Optimice las consultas, tablas y bases de datos mediante Información de rendimiento de consultas y recomendaciones de rendimiento comunes proporcionadas por Microsoft.

• Implemente la lógica de reintento mediante el SDK para mitigar los errores transitorios que afectan a la conectividad de Azure SQL base de datos.

• Dé prioridad al uso de claves administradas por el servicio al aplicar cifrado de datos transparente (TDE) del lado servidor para el cifrado en reposo.

  • Si se requiere el cifrado de claves administradas por el cliente o del lado cliente (AlwaysEncrypted), asegúrese de que las claves sean apropiadamente resistentes con las copias de seguridad y las instalaciones de rotación automatizadas.

• Considere el uso de la restauración a un momento dado como cuaderno de estrategias operativo para recuperarse de errores de configuración graves.

Azure Database For PostgreSQL

• Se recomienda usar el servidor flexible para cargas de trabajo críticas para la empresa debido a su compatibilidad con la zona de disponibilidad.

• Al usar Hiperescala (Citus) para cargas de trabajo críticas para la empresa, habilite el modo de alta disponibilidad para recibir la garantía del Acuerdo de Nivel de Servicio del 99,95 %.

• Use la configuración del servidor hiperescala (Citus) para maximizar la disponibilidad en varios nodos.

• Defina un modelo de capacidad para que la aplicación informe de los requisitos de recursos de proceso y almacenamiento dentro de la plataforma de datos.

  • Considere el descuento por reserva de Hiperescala (Citus) para proporcionar posibles optimizaciones de costos.

Almacenamiento en caché para datos de nivel de acceso frecuente

Se puede aplicar una capa de almacenamiento en caché en memoria para mejorar una plataforma de datos aumentando significativamente el rendimiento de lectura y mejorando los tiempos de respuesta de cliente de un extremo a otro para escenarios de datos de nivel de acceso frecuente.

Azure proporciona varios servicios con funcionalidades aplicables para almacenar en caché estructuras de datos clave, con Azure Cache for Redis posicionadas para abstraer y optimizar el acceso de lectura de la plataforma de datos. Por lo tanto, esta sección se centrará en el uso óptimo de Azure Cache for Redis en escenarios en los que se requiere durabilidad adicional de acceso a datos y rendimiento de lectura.

Consideraciones de diseño

• Una capa de almacenamiento en caché proporciona durabilidad adicional del acceso a los datos, ya que incluso si una interrupción afecta a las tecnologías de datos subyacentes, todavía se puede acceder a una instantánea de datos de la aplicación a través de la capa de almacenamiento en caché.

• En determinados escenarios de carga de trabajo, el almacenamiento en caché en memoria se puede implementar dentro de la propia plataforma de la aplicación.

Azure Cache for Redis

• Redis Cache es un sistema de almacenamiento de clave noSQL código abierto valor en memoria.

• Los niveles Enterprise y Enterprise Flash se pueden implementar en una configuración activa-activa en Availability Zones dentro de una región y diferentes regiones de Azure a través de la replicación geográfica.

  • Cuando se implementa en al menos tres regiones de Azure y tres o más Availability Zones en cada región, con la replicación geográfica activa habilitada para todas las instancias de caché, Azure Cache for Redis proporciona un Acuerdo de Nivel de Servicio del 99,999 % para la conectividad a un punto de conexión de caché regional.
  • Cuando se implementa en tres Availability Zones dentro de una sola región de Azure, se proporciona un Acuerdo de Nivel de Servicio de conectividad del 99,99 %.

• El nivel Enterprise Flash se ejecuta en una combinación de MEMORIA RAM y almacenamiento de memoria no volátil flash, y aunque esto introduce una pequeña penalización de rendimiento, también permite tamaños de caché muy grandes, hasta 13 TB con agrupación en clústeres.

• Con la replicación geográfica, los cargos por la transferencia de datos entre regiones también se aplicarán además de los costos directos asociados a las instancias de caché.

• La característica Scheduled Novedades no incluye actualizaciones ni actualizaciones de Azure aplicadas al sistema operativo de la máquina virtual subyacente.

• Habrá un aumento en el uso de la CPU durante una operación de escalabilidad horizontal mientras los datos se migran a nuevas instancias.

Recomendaciones de diseño

• Considere una capa de almacenamiento en caché optimizada para escenarios de datos de acceso frecuente para aumentar el rendimiento de lectura y mejorar los tiempos de respuesta.

• Aplique las directivas adecuadas para la expiración y el mantenimiento de la memoria caché para evitar el crecimiento de datos descontrolado.

  • Considere la posibilidad de expirar los elementos de caché cuando cambien los datos de respaldo.

Azure Cache for Redis

• Use la SKU Premium o Enterprise para maximizar la confiabilidad y el rendimiento.

  • En el caso de escenarios con volúmenes de datos extremadamente grandes, se debe tener en cuenta el nivel de Enterprise Flash.
  • En escenarios en los que solo se requiere la replicación geográfica pasiva, también se puede tener en cuenta el nivel Premium.

• Implemente instancias de réplica mediante la replicación geográfica en una configuración activa en todas las regiones de implementación consideradas.

• Asegúrese de que las instancias de réplica se implementan en Availability Zones dentro de cada región de Azure considerada.

• Use Azure Monitor para evaluar Azure Cache for Redis.

  • Calcule una puntuación de estado para los componentes de caché regional para observar el estado en relación con los requisitos empresariales y el uso de recursos.
  • Observe y alerte sobre métricas clave, como un uso elevado de CPU, un uso elevado de memoria, una carga de servidor elevada y claves expulsadas para obtener información sobre cuándo escalar la memoria caché.

• Optimice la resistencia de la conexión mediante la implementación de la lógica de reintento, los tiempos de espera y el uso de una implementación singleton del multiplexador de conexión de Redis.

• Configure las actualizaciones programadas para recetar los días y horas en que se aplican las actualizaciones de Redis Server a la memoria caché.

Escenarios analíticos

Es cada vez más habitual que las aplicaciones críticas consideren escenarios analíticos como un medio para impulsar el valor adicional de los flujos de datos incluidos. Por lo tanto, los escenarios analíticos de aplicaciones y operativos (AIOps) forman un aspecto crucial de la plataforma de datos altamente confiable.

Las cargas de trabajo analíticas y transaccionales requieren diferentes funcionalidades y optimizaciones de la plataforma de datos para un rendimiento aceptable dentro de sus respectivos contextos.

Descripción	Analíticos	Transaccional
Caso de uso	Análisis de volúmenes de datos muy grandes ("macrodatos")	Procesar volúmenes muy grandes de transacciones individuales
Optimizado para	Leer consultas y agregaciones en muchos registros	Consultas casi en tiempo real de creación, lectura, actualización y eliminación (CRUD) en pocos registros
Características clave	- Consolidar a partir de orígenes de datos de registro - Almacenamiento basado en columnas - Almacenamiento distribuido - Procesamiento paralelo - Desnormalizado - Lecturas y escrituras de baja simultaneidad - Optimización para el volumen de almacenamiento con compresión	- Origen de datos de registro para la aplicación - Almacenamiento basado en filas - Almacenamiento contiguo - Procesamiento simétrico -Normalizado - Lecturas y escrituras de simultaneidad alta, actualizaciones de índice - Optimización para el acceso rápido a datos con almacenamiento en memoria

Azure Synapse proporciona una plataforma analítica empresarial que reúne datos relacionales y no relacionales con tecnologías de Spark, mediante la integración integrada con servicios de Azure, como Azure Cosmos DB, para facilitar el análisis de macrodatos. Por lo tanto, las consideraciones y recomendaciones de diseño de esta sección se centrarán en el uso óptimo de Azure Synapse y Azure Cosmos DB para escenarios analíticos.

Consideraciones de diseño

• Tradicionalmente, los escenarios analíticos a gran escala se facilitan mediante la extracción de datos en una plataforma de datos independiente optimizada para consultas analíticas posteriores.
  • Las canalizaciones de extracción, transformación y carga (ETL) se usan para extraer datos consumirán rendimiento y afectarán al rendimiento de la carga de trabajo transaccional.
  • La ejecución de canalizaciones de ETL con poca frecuencia para reducir el rendimiento y los impactos en el rendimiento darán lugar a datos analíticos menos actualizados.
  • La sobrecarga de desarrollo y mantenimiento de la canalización ETL aumenta a medida que las transformaciones de datos se vuelven más complejas.
    • Por ejemplo, si los datos de origen se cambian o eliminan con frecuencia, las canalizaciones de ETL deben tener en cuenta esos cambios en los datos de destino para las consultas analíticas a través de un enfoque aditivo o con versiones, volcado y recarga, o cambios en contexto en los datos analíticos. Cada uno de estos enfoques tendrá un impacto derivado, como la nueva creación o actualización del índice.

Azure Cosmos DB

• Las consultas analíticas que se ejecutan en datos transaccionales de Azure Cosmos DB suelen agregarse entre particiones en grandes volúmenes de datos, lo que consume un rendimiento significativo de unidad de solicitud (RU), lo que puede afectar al rendimiento de las cargas de trabajo transaccionales circundantes.

• El almacén analítico de Azure Cosmos DB proporciona un almacén de datos esquematizado y totalmente aislado orientado a columnas que permite el análisis a gran escala en los datos de Azure Cosmos DB desde Azure Synapse sin afectar a las cargas de trabajo transaccionales de Azure Cosmos DB.

  • Cuando un contenedor de Azure Cosmos DB está habilitado como almacén analítico, se crea internamente un nuevo almacén de columnas a partir de los datos operativos del contenedor. Este almacén de columnas se conserva por separado del almacén de transacciones orientado a filas para el contenedor.
  • Las operaciones crear, actualizar y eliminar en los datos operativos se sincronizan automáticamente con el almacén analítico, por lo que no se requiere ninguna fuente de cambios ni procesamiento ETL.
  • La sincronización de datos del almacén analítico al operativo no consume unidades de solicitud de rendimiento (RU) aprovisionadas en el contenedor o la base de datos. No hay ningún impacto en el rendimiento en las cargas de trabajo transaccionales. El almacén analítico no requiere la asignación de RU adicionales en una base de datos o contenedor de Azure Cosmos DB.
  • La sincronización automática es el proceso en el que los cambios de datos operativos se sincronizan automáticamente con el almacén analítico. La latencia de sincronización automática suele ser inferior a dos (2) minutos.
    • La latencia de sincronización automática puede tener hasta cinco (5) minutos para una base de datos con rendimiento compartido y un gran número de contenedores.
    • Tan pronto como se complete la sincronización automática, se pueden consultar los datos más recientes desde Azure Synapse.
  • El almacenamiento del almacén analítico usa un modelo de precios basado en el consumo que cobra por el volumen de datos y el número de operaciones de lectura y escritura. Los precios del almacén analítico son independientes de los precios del almacén transaccional.

• Con Azure Synapse Link, el almacén analítico de Azure Cosmos DB se puede consultar directamente desde Azure Synapse. Esto permite que no-ETL, hybrid Transactional-Analytical Processing (HTAP) de Synapse, de modo que los datos de Azure Cosmos DB se puedan consultar junto con otras cargas de trabajo analíticas de Synapse casi en tiempo real.

• El almacén analítico de Azure Cosmos DB no tiene particiones de forma predeterminada.

  • En determinados escenarios de consulta, el rendimiento mejorará mediante la creación de particiones de datos del Almacén analítico mediante claves que se usan con frecuencia en predicados de consulta.
  • La creación de particiones se desencadena mediante un trabajo en Azure Synapse que ejecuta un cuaderno de Spark mediante Synapse Link, que carga los datos del almacén analítico de Azure Cosmos DB y lo escribe en el almacén con particiones de Synapse en la cuenta de almacenamiento principal del área de trabajo de Synapse.

• Azure Synapse los grupos de SQL Serverless de Analytics pueden consultar el almacén analítico a través de vistas actualizadas automáticamente o a través de SELECT / OPENROWSET comandos.

• Azure Synapse los grupos de Spark de Analytics pueden consultar el almacén analítico mediante tablas spark actualizadas automáticamente o el spark.read comando .

• Los datos también se pueden copiar del almacén analítico de Azure Cosmos DB en un grupo de Synapse SQL dedicado mediante Spark, de modo que se puedan usar los recursos del grupo de SQL Azure Synapse aprovisionados.

• Los datos del Almacén analítico de Azure Cosmos DB se pueden consultar con Azure Synapse Spark.

  • Los cuadernos de Spark permiten que las combinaciones de tramas de datos de Spark agreguen y transformen datos analíticos de Azure Cosmos DB con otros conjuntos de datos y usen otras funcionalidades avanzadas de Synapse Spark, incluida la escritura de datos transformados en otros almacenes o el entrenamiento de modelos de Machine Learning de AIOps.

de

• La fuente de cambios de Azure Cosmos DB también se puede usar para mantener un almacén de datos secundario independiente para escenarios analíticos.

Azure Synapse

• Azure Synapse reúne funcionalidades de análisis, como almacenamiento de datos SQL, macrodatos de Spark y Data Explorer para el análisis de registros y series temporales.

  • Azure Synapse usa servicios vinculados para definir conexiones a otros servicios, como Azure Storage.
  • Los datos se pueden ingerir en Synapse Analytics a través de actividad de copia de orígenes admitidos. Esto permite el análisis de datos en Synapse sin afectar al almacén de datos de origen, pero agrega tiempo, costo y sobrecarga de latencia debido a la transferencia de datos.
  • Los datos también se pueden consultar en contexto en almacenes externos compatibles, evitando la sobrecarga de la ingesta y el movimiento de datos. Azure Storage con Data Lake Gen2 es un almacén compatible para los datos exportados de Synapse y Log Analytics que se pueden consultar a través de Synapse Spark.

• Azure Synapse Studio une tareas de ingesta y consulta.

  • Los datos de origen, incluidos los datos del almacén analítico de Azure Cosmos DB y los datos de exportación de Log Analytics, se consultan y procesan para admitir la inteligencia empresarial y otros casos de uso analíticos agregados.

Recomendaciones de diseño

• Asegúrese de que las cargas de trabajo analíticas no afectan a las cargas de trabajo de aplicaciones transaccionales para mantener el rendimiento transaccional.

Análisis de aplicaciones

• Use Azure Synapse Vínculo con el almacén analítico de Azure Cosmos DB para realizar análisis en los datos operativos de Azure Cosmos DB mediante la creación de un almacén de datos optimizado, que no afectará al rendimiento transaccional.

  • Habilite Azure Synapse Vínculo en cuentas de Azure Cosmos DB.
  • Cree un contenedor habilitado para el almacén analítico o habilite un contenedor existente para el almacén analítico.
  • Conecte el área de trabajo de Azure Synapse al almacén analítico de Azure Cosmos DB para habilitar las cargas de trabajo analíticas en Azure Synapse para consultar datos de Azure Cosmos DB. Use un cadena de conexión con una clave de Azure Cosmos DB de solo lectura.

• Priorice el almacén analítico de Azure Cosmos DB con Azure Synapse Link en lugar de usar la fuente de cambios de Azure Cosmos DB para mantener un almacén de datos analíticos.

  • La fuente de cambios de Azure Cosmos DB puede ser adecuada para escenarios analíticos muy sencillos.

AIOps y Análisis operativos

• Cree un área de trabajo de Azure Synapse única con servicios vinculados y conjuntos de datos para cada cuenta de Azure Storage de origen a la que se envían datos operativos de los recursos.

• Cree una cuenta de Azure Storage dedicada y úsela como cuenta de almacenamiento principal del área de trabajo para almacenar los datos y metadatos del catálogo del área de trabajo de Synapse. Configúrelo con un espacio de nombres jerárquico para habilitar Azure Data Lake Gen2.

  • Mantenga la separación entre los datos analíticos de origen y los datos y los metadatos del área de trabajo de Synapse.
    • No use una de las cuentas regionales o globales de Azure Storage en las que se envían los datos operativos.

Paso siguiente

Revise las consideraciones sobre las consideraciones de red.

Red y conectividad