Compartir vía

Patrones de diseño de fuente de cambios en Azure Cosmos DB for NoSQL

  • Se aplica a: ✅ NoSQL

La fuente de cambios de Azure Cosmos DB le permite procesar de forma eficaz grandes conjuntos de datos con volúmenes de escritura elevados. Proporciona una alternativa a consultar conjuntos de datos completos para identificar los cambios. En este artículo se explican los patrones comunes de diseño de fuente de cambios, sus concesiones y limitaciones para ayudarle a crear soluciones escalables.

Escenarios

Azure Cosmos DB es ideal 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. Entre estas acciones se encuentran las siguientes:

  • Desencadenamiento de una notificación o una llamada a una API cuando se inserta, actualiza o elimina un elemento.
  • Procesamiento de flujos en tiempo real para IoT o análisis de datos operativos.
  • 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 estos patrones, como se muestra en la imagen siguiente:

Diagrama que muestra cómo la fuente de cambios de Azure Cosmos DB aumenta 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 simplifica los escenarios que desencadenan una notificación o llaman a una API en función de un evento específico. Use el procesador de la fuente de cambios para sondear automáticamente el contenedor en busca de cambios y llamar a una API externa para cada escritura, actualización o eliminación.

Desencadene de forma selectiva una notificación o llame a una API en función de criterios específicos. Por ejemplo, si va a leer desde la fuente de cambios mediante Azure Functions, agregue 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 ejecuta para cada cambio, la notificación solo se envía si se cumple la condición.

Procesamiento de secuencias en tiempo real

La fuente de cambios de Azure Cosmos DB le permite realizar el procesamiento de secuencias en tiempo real para IoT o análisis en tiempo real sobre datos operativos. Por ejemplo, reciba y almacene datos de eventos de dispositivos, sensores, infraestructura y aplicaciones, y luego procesarlos en tiempo real mediante Spark. En la siguiente imagen se muestra cómo implementar una arquitectura lambda mediante la fuente de cambios de Azure Cosmos DB:

Diagrama en el que se 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 baja latencia de lectura y escritura garantizada.

Persistencia de los datos

Los datos escritos en Azure Cosmos DB aparecen en la fuente de cambios. En el modo de última versión, los datos permanecen en la fuente de cambios hasta la eliminació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, ejecute 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 tanto, si lee los datos del feed de cambios, los datos son siempre consistentes con las consultas del mismo contenedor de Azure Cosmos DB.

Alta disponibilidad

Azure Cosmos DB proporciona 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 con un RTO (objetivo de tiempo de recuperación) de cero.

Después de procesar los elementos de la fuente de cambios, compile una vista materializada y conserve los valores agregados de nuevo en Azure Cosmos DB. Por ejemplo, use la fuente de cambios de Azure Cosmos DB para implementar marcadores en tiempo real en función de las puntuaciones de los juegos completados.

Movimiento de datos

Lea desde la fuente de cambios para el movimiento de datos en tiempo real.

Por ejemplo, la fuente de cambios le permite realizar las siguientes tareas de forma 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 tiempo 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, almacene "datos de acceso frecuente" en Azure Cosmos DB y quite "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 garantiza 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 usa de un almacén de solo anexar para registrar la serie completa de acciones en los 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 operaciones de escritura (sin actualizaciones ni eliminaciones). En este caso, cada operación de 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 los de mantenimiento de las vistas materializadas o de 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, 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. Para reproducir actualizaciones individuales anteriores a un elemento, modele estas actualizaciones como una serie de escrituras o use 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. Al eliminar un elemento del contenedor, el elemento se quita de la fuente de cambios. El método más común para controlar las operaciones de eliminación es agregar un marcador temporal a 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.

Retention

La fuente de cambios en el modo de la última versión 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. Asegúrese de seleccionar una clave de partición que le ofrezca una garantía de un orden significativo.

Considere una aplicación comercial que usa el modelo de diseño de aprovisionamiento de eventos. En esta aplicación, cada una de las distintas acciones de usuario se considera un "evento" que se modela como una escritura 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 realiza el pago y se envía el contenido del carrito de compras.

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. Por ejemplo, si la compra del carro se procesara antes de la eliminación del elemento A, es probable que el elemento A se envíe al cliente en lugar del elemento B que el cliente quería. Para asegurarse de que estos cuatro eventos se procesan en orden, 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.

Examples

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

Contenido relacionado

  • Last updated on