Modelos de diseño de la fuente de cambios de Azure Cosmos DB

  • Artículo

SE APLICA A: NoSQL

La fuente de cambios de Azure Cosmos DB permite un procesamiento eficaz de grandes conjuntos de datos que tienen un elevado volumen de escritura. La fuente de cambios también ofrece una alternativa a las consultas de conjuntos de datos completos para identificar qué ha cambiado. Este artículo se centra en los modelos de diseño comunes de la fuente de cambios, las compensaciones del diseño y las limitaciones de la fuente de cambios.

Azure Cosmos DB es adecuado para IoT, juegos y aplicaciones de registro de operaciones. Un modelo de diseño común en estas aplicaciones es usar los cambios en los datos para desencadenar otras acciones. Algunos ejemplos de acciones incluyen:

  • Desencadenamiento de una notificación o una llamada a una API cuando se inserta, actualiza o elimina un elemento.
  • Procesamiento de secuencias en tiempo real para IoT o procesamiento de estadísticas sobre datos operativos en tiempo real.
  • Movimiento de datos, como la sincronización con una memoria caché, un motor de búsqueda, un almacenamiento de datos o el almacenamiento en frío.

La fuente de cambios en Azure Cosmos DB le permite crear soluciones eficientes y escalables para cada uno de estos patrones, como se muestra en la imagen siguiente:

Diagrama que muestra el uso de la fuente de cambios de Azure Cosmos DB para aumentar la eficacia de los escenarios de informática orientada a eventos y análisis en tiempo real.

Procesamiento de eventos y notificaciones

La fuente de cambios de Azure Cosmos DB puede simplificar los escenarios que necesitan desencadenar una notificación o enviar una llamada a una API en función de un evento determinado. Puede usar el procesador de la fuente de cambios para sondear automáticamente el contenedor en busca de cambios y, a continuación, llamar a una API externa cada vez que haya una escritura, actualización o eliminación.

También puede desencadenar una notificación de forma selectiva o enviar una llamada a una API en función de criterios específicos. Por ejemplo, si está leyendo desde la fuente de cambios mediante Azure Functions, puede colocar la lógica en la función para enviar una notificación solo si se cumple una condición. Aunque el código de la función de Azure se ejecutaría para cada cambio, la notificación solo se enviaría si se cumple la condición.

Procesamiento de secuencias en tiempo real

La fuente de cambios de Azure Cosmos DB se puede usar para el procesamiento de secuencias en tiempo real para IoT o el procesamiento de estadísticas sobre datos operativos en tiempo real. Por ejemplo, puede recibir y almacenar datos de eventos de dispositivos, sensores, infraestructura y aplicaciones, y luego procesarlos en tiempo real con Spark. En la siguiente imagen se muestra cómo puede implementar la arquitectura lambda mediante la fuente de cambios de Azure Cosmos DB:

Diagrama que muestra una canalización Lambda basada en Azure Cosmos DB para ingesta y consulta.

En muchos casos, las implementaciones de procesamiento de secuencias reciben primero un gran volumen de datos entrantes en una cola de mensajes temporal, como Azure Event Hubs o Apache Kafka. La fuente de cambios es una alternativa excelente debido a la capacidad de Azure Cosmos DB para admitir una alta tasa de ingesta de datos con una latencia de lectura y escritura baja garantizada. Las ventajas de la fuente de cambios de Azure Cosmos DB en una cola de mensajes incluyen:

Persistencia de los datos

Los datos escritos en Azure Cosmos DB se muestran en la fuente de cambios. Los datos se conservan en la fuente de cambios hasta que se eliminan si lee mediante el Modo Última versión. Las colas de mensajes suelen tener un período de retención máximo. Por ejemplo, Azure Event Hubs ofrece una retención de datos máxima de 90 días.

Capacidad de consulta

Además de leer la fuente de cambios de un contenedor de Azure Cosmos DB, puede ejecutar consultas SQL en los datos almacenados en Azure Cosmos DB. La fuente de cambios no es una duplicación de los datos que ya están en el contenedor, sino simplemente un mecanismo diferente para leer los datos. Por lo tanto, si lee los datos desde la fuente de cambios, los datos son siempre coherentes con las consultas del mismo contenedor de Azure Cosmos DB.

Alta disponibilidad

Azure Cosmos DB ofrece hasta un 99,999 % de disponibilidad de lectura y escritura. A diferencia de muchas colas de mensajes, los datos de Azure Cosmos DB se pueden distribuir y configurar globalmente de forma sencilla con un RTO (objetivo de tiempo de recuperación) de cero.

Después de procesar los elementos de la fuente de cambios, puede compilar una vista materializada y conservar los valores agregados de nuevo en Azure Cosmos DB. Si usa Azure Cosmos DB para compilar un juego, puede usar la fuente de cambios para, por ejemplo, implementar marcadores en tiempo real basados en las puntuaciones de los juegos completados.

Movimiento de datos

También puede leer desde la fuente de cambios para el movimiento de datos en tiempo real.

Por ejemplo, la fuente de cambios le ayuda a realizar las siguientes tareas de manera eficaz:

  • Actualizar una memoria caché, un índice de búsqueda o un almacenamiento de datos con los datos almacenados en Azure Cosmos DB.

  • Realizar migraciones sin tiempos de inactividad a otra cuenta de Azure Cosmos DB o a otro contenedor de Azure Cosmos DB que tenga una clave de partición lógica diferente.

  • Implemente un archivado y una capa de datos de nivel de aplicación. Por ejemplo, puede almacenar "datos de acceso frecuente" en Azure Cosmos DB y quitar "datos inactivos" en otros sistemas de almacenamiento, como Azure Blob Storage.

Si tiene que desnormalizar los datos entre las particiones y los contenedores, puede leer desde la fuente de cambios del contenedor como origen de esta replicación de datos. La replicación de datos en tiempo real con la fuente de cambios solo puede garantizar la coherencia final. Puede supervisar hasta qué punto el procesador de la fuente de cambios se retrasa en el procesamiento de cambios en el contenedor de Azure Cosmos DB.

Aprovisionamiento de eventos

El patrón de aprovisionamiento de eventos implica el uso de un almacén de solo anexar para registrar la serie completa de acciones en esos datos. La fuente de cambios de Azure Cosmos DB es una excelente opción como almacén de datos central en las arquitecturas de aprovisionamiento de eventos, en las que toda la ingesta de datos se modela como escritura (sin actualizaciones ni eliminaciones). En este caso, cada escritura en Azure Cosmos DB es un "evento", lo que significa que hay un registro completo de los eventos pasados en la fuente de cambios. Los usos habituales de los eventos publicados por el almacén de eventos central son el mantenimiento de las vistas materializadas o la integración con sistemas externos. Dado que no hay ningún límite de tiempo para la retención en el modo de versión más reciente de la fuente de cambios, puede reproducir todos los eventos pasados leyendo desde el principio de la fuente de cambios del contenedor de Azure Cosmos DB. Puede incluso hacer que varios consumidores de fuentes de cambios se suscriban a la misma fuente de cambios del contenedor.

Azure Cosmos DB es un excelente almacén de datos persistentes central de solo anexar en el patrón de aprovisionamiento de eventos debido a sus ventajas en la escalabilidad horizontal y alta disponibilidad. Además, el procesador de fuente de cambios ofrece una garantía de "al menos una vez", lo que garantiza que no se perderá el procesamiento de los eventos.

Limitaciones actuales

La fuente de cambios tiene varios modos y, cada uno de ellos, tiene limitaciones importantes que debe comprender. Hay varias áreas que se deben tener en cuenta al diseñar una aplicación que usa la fuente de cambios en el modo de versión más reciente o en el modo de todas las versiones y eliminaciones.

Actualizaciones intermedias

En el modo de versión más reciente, solo el cambio más reciente en un elemento específico se incluye en la fuente de cambios. Al procesar los cambios, se lee la última versión disponible del elemento. Si hay varias actualizaciones para el mismo elemento en un breve período de tiempo, es posible que se pierda el procesamiento de las actualizaciones intermedias. Si desea reproducir actualizaciones individuales anteriores a un elemento, puede modelar estas actualizaciones como una serie de escrituras en su lugar o usar el modo de todas las versiones y eliminaciones.

Eliminaciones

El modo de versión más reciente de la fuente de cambios no captura eliminaciones. Si elimina un elemento del contenedor, también se quita de la fuente de cambios. El método más común para controlar eliminaciones consiste en agregar un marcador flexible en los elementos que se van a eliminar. Puede agregar una propiedad denominada deleted y establecerla en true en el momento de la eliminación. Esta actualización del documento se muestra en la fuente de cambios. Puede establecer un período de vida (TTL) en este elemento para que se pueda eliminar automáticamente más adelante.

Retención

La fuente de cambios en el modo de versión más reciente tiene una retención ilimitada. Siempre que exista un elemento en el contenedor, está disponible en la fuente de cambios.

Orden garantizado

Todos los modos de fuente de cambios tienen un orden garantizado dentro de un valor de clave de partición, pero no en todos los valores de clave de partición. Debe seleccionar una clave de partición que proporcione una garantía de orden significativa.

Por ejemplo, considere que una aplicación comercial usa el modelo de diseño de aprovisionamiento de eventos. En esta aplicación, las distintas acciones de usuario son cada uno de los "eventos" que se modelan como escrituras en Azure Cosmos DB. Imagine si algunos eventos de ejemplo se producen en la secuencia siguiente:

  1. El cliente agrega el elemento A al carro de la compra.
  2. El cliente agrega el elemento B al carro de la compra.
  3. El cliente elimina el elemento A del carro de la compra.
  4. El cliente paga y se envía el contenido del carro de la compra.

Se mantiene una vista materializada del contenido del carro de la compra actual para cada cliente. Esta aplicación debe asegurarse de que estos eventos se procesen en el orden en que se producen. Si, por ejemplo, el pago del carro se procesara antes de la retirada del artículo A, es probable que el artículo A se hubiera enviado al cliente, en lugar del artículo que el cliente quería, el artículo B. Para garantizar que estos cuatro eventos se procesan en orden de aparición, deben estar dentro del mismo valor de clave de partición. Si selecciona username (cada cliente tiene un nombre de usuario único) como clave de partición, puede garantizar que estos eventos aparezcan en la fuente de cambios en el mismo orden en el que se escriben en Azure Cosmos DB.

Ejemplos

Estos son algunos ejemplos reales de código de fuente de cambios para el modo de versión más reciente que van más allá del ámbito de los ejemplos proporcionados:

Pasos siguientes