¿Cómo puedo consumir el canal de información de cambios?

En una única base de datos orders, puedo pedir a la base de datos una lista de cambios, en este caso, limitando el conjunto de resultados a cinco cambios con ?limit=5:

GET /orders/_changes?limit=5
{
  "results": [
    {
      "seq": "1-g1AAAAB5eJzLYWBg",
      "id": "00002Sc12XI8HD0YIBJ92n9ozC0Z7TaO",
      "changes": [
        {
          "rev": "1-3ef45fdbb0a5245634dc31be69db35f7"
        }
      ]
    },
    ....
  ],
  "last_seq": "5-g1AAAAB5eJzLYWBg"
}

La llamada a la API devuelve los cambios siguientes:

results

Una matriz de cambios.

last_seq

Un token que se puede proporcionar al punto final de cambios en una llamada posterior a la API para obtener el siguiente lote de cambios.

Consulte cómo extraer el siguiente lote de cambios en el ejemplo siguiente:

GET /orders/_changes?limit=5&since=5-g1AAAAB5eJzLYWBg
{
  "results": [ ...],
  "last_seq": "10-g1AAAACbeJzLY"
}

El parámetro since se utiliza para definir en qué lugar del canal de información de cambios desea empezar:

since=0

El inicio de la serie de cambios.

since=now

Fin de la secuencia de cambios.

since=<a last seq token>

Desde un lugar conocido en el feed de cambios.

A primera vista, el seguimiento del canal de información de cambios parece tan simple como encadenar las llamadas de API de _changes. A continuación, IBM Cloudant pasa la respuesta last_seq from one changes feed al parámetro since de la siguiente solicitud. Pero algunas sutilezas de los cambios en los alimentos necesitan más debate.

¿Por qué el canal de cambios muestra cada cambio al menos una vez?

La norma « IBM Cloudant » establece que los flujos de datos deben garantizar que cada documento se devuelva al menos una vez, lo cual no es lo mismo que garantizar que cada documento se devuelva solo una vez. Dicho de otra manera, es posible que un consumidor de changes feed vea el mismo cambio de nuevo, o de hecho un conjunto de cambios repetidos.

Un consumidor del canal de información de cambios debe tratar los cambios idempotentemente. En la práctica, debe recordar si un cambio ya se ha manejado antes de desencadenar una acción a partir de un cambio. Un consumidor ingenuo del canal de información de cambios podría enviar un mensaje a un teléfono inteligente para cada cambio recibido. Pero un usuario podría recibir mensajes de texto duplicados si un cambio no se maneja con idempotencia cuando se reproducen cambios ya manejados.

Por lo general estos "retrocesos" del canal de información de cambios de alimentación son cortos y solo reproducen unos pocos cambios. Pero en algunos casos, una solicitud podría ver una respuesta con miles de cambios reproducidos, potencialmente todos los cambios desde el principio del tiempo. El potencial de rewinds hace que el changes feed sea inadecuado para una aplicación que espera un comportamiento de tipo cola.

Insistimos en que el servicio de cambios de IBM Cloudant garantiza que un documento aparecerá al menos una vez en un feed de cambios, pero no ofrece ninguna garantía respecto a la repetición de valores en varias solicitudes.

¿El canal de información de cambios funciona en "tiempo real"?

El canal de información de cambios no garantiza la rapidez con la que un cambio de entrada se mostrará a un cliente que consume el canal de información de cambios. Las aplicaciones no deben desarrollarse con la suposición de que las inserciones de datos, las actualizaciones y las supresiones se propagarán inmediatamente a un lector de cambios.

¿Por qué no aparecen todos los cambios de documento individuales en el canal de información de cambios?

Si un documento se actualiza varias veces entre una llamada al servicio de cambios y otra, es posible que dicho servicio solo refleje el último de esos cambios. El cliente no recibe cada cambio en cada documento.

El canal de información de cambios de IBM Cloudant no es un registro de transacciones que contiene cada suceso que se ha producido en el orden temporal.

¿Puedo utilizar un canal de información de cambios filtrados para consultas operativas?

Filtrar el flujo de cambios y, por extensión, ejecutar una replicación filtrada tiene sus ventajas:

• Copiar datos del origen al destino, pero omitir los documentos suprimidos.
• Copiar datos pero sin definiciones de índice (documentos de diseño).

Esta publicación de blog describe cómo el suministro de un selector durante la réplica hace que el trabajo de estos casos de uso se ejecute sin problemas.

El canal de información de cambios con un parámetro selector que lo acompaña no es el modo de extraer porciones de datos de la base de datos de forma rutinaria. No debe utilizarse como medio para realizar consultas operativas en una base de datos. Los cambios filtrados son lentos (el filtro se aplica a cada documento modificado a su vez, sin la ayuda de un índice). Este proceso es mucho más lento que crear un índice secundario (como una vista MapReduce) y consultar esa vista.

¿Un canal de información de cambios de feed=continuous continúa ejecutándose indefinidamente?

No, IBM Cloudant no garantiza la duración de la conexión para un canal de información de cambios continuos. El servidor puede desconectarlo periódicamente por diversas razones, entre las que se incluyen el mantenimiento, la seguridad o los errores de red. El código que utiliza el canal de información de cambios debe estar diseñado para utilizar un ID de secuencia guardado recientemente como un valor since para que una nueva solicitud pueda reanudar el canal de información de cambios después de un error o una desconexión.

¿Por qué el canal de información de cambios no garantiza el orden temporal?

Si el caso de uso se basa en la sentencia siguiente, este resultado no se puede lograr con el canal de información de cambios de IBM Cloudant.

"Fetch me every document that has changed since a known date, in the order they were written."

La base de datos de IBM Cloudant no registra la hora en la que se ha escrito cada cambio de documento. El canal de información de cambios no garantiza el orden de los cambios en el canal de información; no se garantiza que estén en el orden en que se enviaron a la base de datos.

Sin embargo, puede conseguir este caso de uso almacenando la fecha de cambio en el cuerpo del documento:

{
  "_id": "2657",
  "type": "order",
  "customer": "bob@aol.com",
  "order_date": "2022-01-05T10:40:00",
  "status": "dispatched",
  "last_edit_date": "2022-01-14T19:17:20"
}

Y puede crear una vista MapReduce con last_edit_date como la clave:

function(doc) {
  emit(doc.last_edit_date, null)
}

Esta vista se puede consultar para devolver cualquier documento que se haya modificado en o después de una fecha y hora proporcionadas:

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"

Esta técnica genera un conjunto de resultados ordenados en el tiempo sin valores repetidos de forma idónea y repetible. El usuario de estos datos no necesita gestionarlos de forma idempotente, lo que simplifica el proceso de desarrollo.

¿Cuál es el beneficio del canal de información de cambios de IBM Cloudant por ahora?

El canal de información de cambios de IBM Cloudant es eficaz para las tareas siguientes:

• Ejecución de la réplica de IBM Cloudant, opcionalmente con un selector para filtrar algunos cambios.
• Los clientes consumen el flujo de cambios por lotes, pero tratan cada cambio de forma idempotente, sin preocuparse por el orden de clasificación y esperando ver algunos cambios más de una vez.

El canal de información de cambios de IBM Cloudant no es eficaz para los siguientes componentes:

• Una cola de mensajes. Para obtener más información, consulta IBM Messages for RabbitMQ sobre la gestión de colas.
• Un intermediario de mensajes. Para obtener más información, consulta IBM Event Streams sobre cómo gestionar flujos de eventos escalables y ordenados cronológicamente.
• Un sistema de publicación y suscripción en tiempo real. Para obtener más información, consulta IBM Databases for Redis sobre cómo gestionar los temas de publicación y suscripción.
• Un registro de transacciones. Algunas bases de datos almacenan cada cambio en un registro de transacciones, pero la naturaleza distribuida y de consistencia eventual de IBM Cloudant implica que no existe un registro de transacciones definitivo ordenado cronológicamente.
• Un mecanismo de consulta. Para obtener más información, consulte Vistas MapReduce para crear vistas de los datos ordenados por una clave de su elección.