Como consumir o feed de mudanças?

Dado um único banco de dados orders, posso solicitar ao banco de dados uma lista de mudanças, neste caso, limitando o resultado configurado para cinco mudanças com ?limit=5:

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

A chamada da API retorna as mudanças a seguir:

results

Uma matriz de mudanças.

last_seq

Um token que pode ser fornecido ao endpoint de alterações em uma chamada de API subsequente para obter o próximo lote de alterações.

Veja como buscar o próximo lote de mudanças no exemplo a seguir:

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

O parâmetro since é usado para definir de onde no feed de mudanças você deseja iniciar:

since=0

O início do feed de atualizações.

since=now

Fim do feed de alterações.

since=<a last seq token>

De um local conhecido no feed de alterações.

No valor de face, seguir o feed de mudanças parece tão simples quanto encadear as chamadas API do _changes juntas. Em seguida, o IBM Cloudant passa o last_seq de uma resposta changes feed para o parâmetro since da próxima solicitação. Mas algumas sutilezas no feed de mudanças precisam de mais discussão.

Por que o feed de alterações exibe cada alteração pelo menos uma vez?

A norma “ IBM Cloudant ” altera a promessa de que o feed retornará cada documento pelo menos uma vez, o que não é o mesmo que prometer retornar cada documento apenas uma vez. Colocado de outra forma, é possível que um consumidor do changes feed veja a mesma mudança novamente ou, de fato, um conjunto de mudanças repetido.

Um consumidor do feed de mudanças deve tratar as mudanças idempotentamente. Na prática, deve-se lembrar se uma mudança já foi tratada antes de acionar uma ação por meio de uma mudança. Um consumidor ingênuo de feed de mudanças pode enviar uma mensagem para um smartphone a cada mudança recebida. Mas um usuário pode receber mensagens de texto duplicadas se uma mudança não for tratada idempotentemente quando ocorrerem mudanças reproduzidas.

Geralmente, esses "retrocessos" do feed de mudanças são curtos, reproduzindo apenas algumas mudanças. Mas, em alguns casos, uma solicitação pode ver uma resposta com milhares de mudanças reproduzidas - potencialmente todas as mudanças desde o início do tempo. O potencial para rewinds torna o changes feed inadequado para um aplicativo que espera um comportamento semelhante à fila.

Para reiterar, o feed de mudanças do IBM Cloudantpromete entregar um documento pelo menos uma vez em um feed de mudanças e não fornece garantias sobre valores repetidos em diversas solicitações.

O feed de mudanças opera em "tempo real"?

O feed de mudanças não garante o quão rapidamente uma mudança recebida aparece para um cliente que consome o feed de mudanças. Os aplicativos não devem ser desenvolvidos com a suposição de que inserções de dados, atualizações e exclusões são imediatamente propagadas para um leitor de mudanças.

Por que todas as mudanças de documentos individuais não aparecem no feed de mudanças?

Se um documento for atualizado várias vezes entre as chamadas de feed de mudanças, o feed de mudanças poderá refletir apenas a mais recente dessas mudanças. O cliente não recebe cada mudança em cada documento.

O feed de mudanças do IBM Cloudant não é um log de transações que contém todos os eventos que aconteceram em ordem temporal.

É possível usar um feed de mudanças filtrado para consultas operacionais?

Filtrar o feed de alterações e, por extensão, executar a replicação filtrada tem suas utilidades:

• Copiar dados da origem para o destino, mas ignorar documentos excluídos.
• Copiar dados, mas sem definições de índice (documentos de design).

Esta postagem do blog descreve como fornecer um selector durante a replicação faz com que o trabalho desses casos de uso seja executado sem problemas.

O feed de mudanças com um parâmetro selector que acompanha não é a maneira de extrair fatias de dados do banco de dados em uma base de rotina. Não deve ser utilizado como meio de executar consultas operacionais em um banco de dados. As mudanças filtradas são lentas (o filtro é aplicado a cada documento alterado por vez, sem a ajuda de um índice). Esse processo é muito mais lento do que criar um índice secundário (como uma visualização MapReduce ) e consultar essa visualização.

Um feed de mudanças do feed=continuous continua a ser executado indefinidamente?

Não, IBM Cloudant não garante a duração da conexão para um feed de mudanças contínuas. Ele pode ser desconectado regularmente pelo servidor por diversos motivos, entre os quais manutenção, segurança ou erros de rede. Código que usa o feed de mudanças deve ser projetado para usar um ID de sequência recentemente salvo como um valor since para fazer uma nova solicitação para retomar o feed de mudanças após um erro ou desconexão.

Por que o feed de mudanças não garante alimentam a ordenação temporal?

Se o caso de uso for baseado na instrução a seguir, então esse resultado não poderá ser alcançado com o feed de mudanças do IBM Cloudant.

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

O banco de dados IBM Cloudant não registra o tempo em que cada mudança de documento foi gravada. O feed de mudanças não garante a ordenação das mudanças no feed - não há garantia de que elas estarão na ordem em que foram enviadas para o banco de dados.

No entanto, é possível realizar esse caso de uso, armazenando a data de mudança no corpo do 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"
}

E é possível criar uma visualização MapReduce com last_edit_date como a chave:

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

Esta visualização pode ser consultada para retornar quaisquer documentos modificados em ou após uma data e hora fornecidos:

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

Esta técnica produz um conjunto de resultados ordenados por tempo sem valores repetidos com bom desempenho replicável. O usuário desses dados não precisa gerenciá-los de forma idempotente, o que simplifica o processo de desenvolvimento.

Em que o feed de mudanças do IBM Cloudant é bom agora?

O feed de mudanças do IBM Cloudant é bom para as tarefas a seguir:

• Ligando a replicação do IBM Cloudant, opcionalmente com um seletor para filtrar algumas mudanças.
• Os clientes consomem o feed de alterações em lotes, mas tratam cada alteração de forma idempotente, sem se preocuparem com a ordem de classificação e esperando ver algumas alterações mais de uma vez.

O feed de mudanças fo IBM Cloudant não é bom para os componentes a seguir:

• Uma fila de mensagens. Para obter mais informações, consulte IBM Messages for RabbitMQ sobre o gerenciamento de filas.
• Um broker de mensagens. Para obter mais informações, consulte IBM Event Streams sobre como lidar com fluxos de eventos escaláveis e ordenados por tempo.
• Um sistema de publicação e assinatura em tempo real. Para obter mais informações, consulte IBM Databases for Redis sobre como lidar com tópicos de publicação e assinatura.
• Um log de transações. Alguns bancos de dados armazenam cada alteração em um log de transações, mas a natureza distribuída e eventualmente consistente de um “ IBM Cloudant ” significa que não existe um log de transações definitivo ordenado por tempo.
• Um mecanismo de consulta. Para obter mais informações, consulte MapReduce Visualizações para criar visualizações de seus dados que são ordenados por uma chave de sua escolha.