Compartir a través de

Lectura de la fuente de cambios de Azure Cosmos DB

  • Artículo

SE APLICA A: NoSQL

Puede trabajar con la fuente de cambios de Azure Cosmos DB mediante un modelo de inserción o un modelo de extracción. Con un modelo de inserción, el procesador de fuente de cambios envía el trabajo a un cliente que tiene la lógica de negocios para procesarlo. Sin embargo, el procesador de fuente de cambios se encarga de la complejidad de comprobar el trabajo y almacenar el estado del último trabajo procesado.

Con un modelo de extracción, el cliente tiene que extraer el trabajo del servidor. En este caso, el cliente no solo tiene lógica de negocios para procesar el trabajo, sino que también almacena el estado del último trabajo procesado. De este modo, se encarga del equilibrio de carga entre varios clientes que procesan el trabajo en paralelo, así como de los errores.

Para leer la fuente de cambios de Azure Cosmos DB, normalmente se recomienda usar un modelo de inserción, ya que no es necesario preocuparse por lo siguiente:

  • Sondeo de la fuente de cambios para los cambios futuros.
  • Almacenamiento del estado del último cambio procesado. Si lee desde el procesador de fuente de cambios, el estado se almacena de forma automática en un contenedor de concesión.
  • Equilibrio de la carga entre varios clientes que consumen cambios. Por ejemplo, si un cliente no puede hacer frente al procesamiento de los cambios y otro tiene capacidad disponible.
  • Control de errores. Por ejemplo, los cambios que no se procesaron correctamente se vuelven a intentar automáticamente después de una excepción no controlada en el código o un problema de red transitorio.

La mayoría de los escenarios en los que se usa la fuente de cambios de Azure Cosmos DB usarán una de las opciones del modelo de inserción. Sin embargo, hay algunas situaciones en las que es preferible el control de bajo nivel adicional del modelo de extracción. Entre ellas se incluyen las siguientes:

  • Leer cambios de una clave de partición determinada.
  • Controlar el ritmo con el que el cliente recibe los cambios para procesarlos.
  • Realizar una lectura única de los datos existentes en la fuente de cambios (por ejemplo, para realizar una migración de datos).

Lectura de la fuente de cambios con un modelo de inserción

Usar un modelo de inserción es la forma más fácil de leer la fuente de cambios. Hay dos formas de leer desde la fuente de cambios con un modelo de inserción: los desencadenadores de Azure Functions para Azure Cosmos DB y el procesador de fuente de cambios. Azure Functions usa el procesador de fuente de cambios en segundo plano, por lo que ambas son formas similares de leer la fuente de cambios. Simplemente, piense en Azure Functions como una plataforma de hospedaje para el procesador de fuente de cambios, no como una forma totalmente diferente de leer la fuente de cambios.

Azure Functions

Azure Functions es la opción más sencilla si acaba de empezar a usar la fuente de cambios. Debido a su simplicidad, también es la opción recomendada para la mayoría de los casos de uso de la fuente de cambios. Cuando cree un desencadenador de Azure Functions para Azure Cosmos DB, seleccione el contenedor al que conectarse, y la instancia de Azure Functions se desencadenará siempre que se realice un cambio en el contenedor. Dado que Azure Functions usa el procesador de fuente de cambios en segundo plano, ejecuta en paralelo de forma automática el procesamiento de los cambios en las particiones del contenedor.

El desarrollo con Azure Functions es una experiencia sencilla y puede resultar más rápida que implementar el procesador de fuente de cambios por su cuenta. Los desencadenadores pueden crearse con el portal de Azure Functions o mediante programación con los SDK. Visual Studio y VS Code proporcionan compatibilidad para escribir funciones de Azure Functions e incluso puede usar la CLI de Azure Functions para el desarrollo multiplataforma. Puede escribir y depurar el código en el escritorio y, luego, implementar la función con un botón. Consulte los artículos Informática de base de datos sin servidor con Azure Functions y Uso de la fuente de cambios con Azure Functions para obtener más información.

Biblioteca de procesadores de fuente de cambios

SDK admitidos

.Net V3 Java Node.JS Python
✓ ✓ ✕ ✕

El procesador de fuente de cambios proporciona un mayor control sobre la fuente de cambios y oculta también la mayor parte de la complejidad. La biblioteca de procesadores de fuente de cambios sigue el patrón de observador, en el que la biblioteca llama a la función de procesamiento. El procesador de la fuente de cambios comprobará automáticamente si hay cambios y, si se encuentran, los "inserta" en el cliente. Si tiene una fuente de cambios de alto rendimiento, puede crear instancias de varios clientes para leer la fuente de cambios. El procesador de fuente de cambios dividirá automáticamente la carga entre distintos clientes. No tendrá que implementar ninguna lógica para el equilibrio de cargas entre varios clientes, ni ninguna lógica para mantener el estado de la concesión.

El procesador de fuente de cambios garantiza una entrega de "al menos una vez" de todos los cambios. Es decir, si usa el procesador de fuente de cambios, la función de procesamiento se llamará correctamente por cada elemento de la fuente de cambios. Si hay una excepción no controlada en la lógica de negocios de la función de procesamiento, los cambios con errores se volverán a intentar hasta que se procesen correctamente. Para evitar que el procesador de fuente de cambios se "atasque" al reintentar continuamente los mismos cambios, agregue lógica en la función de procesamiento para escribir documentos, en caso de excepción, en una cola de mensajes fallidos. Más información sobre el control de errores.

En Azure Functions, la recomendación para controlar los errores es la misma. Aún debe agregar lógica en el código de delegado para escribir documentos, en caso de excepción, en una cola de mensajes fallidos. Pero si hay una excepción no controlada en la instancia de Azure Functions, el cambio que haya ocasionado la excepción no se volverá a intentar automáticamente. Si hay una excepción no controlada en la lógica de negocios, la instancia de Azure Functions procesará el siguiente cambio. La función de Azure Functions no volverá a intentar el mismo cambio con errores.

Al igual que con Azure Functions, el desarrollo resulta fácil con la biblioteca de procesadores de fuente de cambios. Pero tiene la responsabilidad de implementar uno o más hosts para el procesador de fuente de cambios. Un host es una instancia de aplicación que usa el procesador de fuente de cambios para escuchar los cambios. Aunque Azure Functions tiene funcionalidades para escalado automático, su responsabilidad es escalar los hosts. Para obtener más información, consulte Uso del procesador de fuente de cambios. La biblioteca de procesadores de fuente de cambios es parte del SDK V3 de Azure Cosmos DB.

Lectura de la fuente de cambios con un modelo de extracción

El modelo de extracción de fuente de cambios permite consumir la fuente de cambios a su propio ritmo. El cliente debe solicitar los cambios y no hay ningún sondeo automático de cambios. Si quiere "marcar" de forma permanente el último cambio procesado (de manera similar al contenedor de concesión del modelo de inserción), debe guardar un token de continuación.

Con el modelo de extracción de fuente de cambios, obtiene un control de nivel más bajo sobre la fuente de cambios. Cuando lee la fuente de cambios con el modelo de extracción, tiene tres opciones:

  • Leer los cambios de un contenedor completo.
  • Leer los cambios de un FeedRange específico.
  • Leer los cambios de un valor de clave de partición específico.

Puede ejecutar en paralelo el procesamiento de los cambios en varios clientes, del mismo modo que con el procesador de fuente de cambios. Pero el modelo de extracción no controla automáticamente el equilibrio de carga entre clientes. Cuando se usa el modelo de extracción para el procesamiento paralelo de la fuente de cambios, primero se obtiene una lista de FeedRanges. Un FeedRange contiene un intervalo de valores de clave de partición. Deberá tener un proceso de orquestador que obtenga los FeedRanges y los distribuya entre sus máquinas. Después, puede usar estos FeedRanges para que varias máquinas lean la fuente de cambios en paralelo.

No hay ninguna garantía de entrega "al menos una vez" incluida en el modelo de extracción. Este le ofrece un control de bajo nivel para decidir cómo quiere administrar los errores.

Fuente de cambios en las API de Cassandra y MongoDB

La funcionalidad de fuente de cambios aparece como flujos de cambios en la API de MongoDB y como consulta con predicado en una API de Cassandra. Para más información sobre los detalles de implementación de la API de MongoDB, consulte Flujos de cambios en Azure Cosmos DB for MongoDB.

Apache Cassandra nativo proporciona un mecanismo de captura de datos modificados (CDC), que permite marcar tablas concretas para el archivado, así como rechazar escrituras en esas tablas una vez que se alcanza un tamaño en disco configurable para el registro de CDC. La característica de fuente de cambios en Azure Cosmos DB for Apache Cassandra mejora la capacidad de consultar los cambios con el predicado a través de CQL. Para más información sobre los detalles de implementación, consulte Fuente de cambios en Azure Cosmos DB for Apache Cassandra.

Pasos siguientes

Ahora, puede seguir aprendiendo acerca de las fuentes de cambios en los siguientes artículos: