Padrões de design do feed de alterações no Azure Cosmos DB

APLICA-SE A: NoSQL

O feed de alterações do Azure Cosmos DB permite o processamento eficiente de grandes conjuntos de dados que possuem um alto volume de gravações. O feed de alterações também oferece uma alternativa para consultar todo um conjunto de dados para identificar o que foi alterado. Este artigo se concentra em padrões de design comuns do feed de alterações, compensações de design e limitações do feed de alterações.

O Azure Cosmos DB é adequado para IoT, jogos, varejo e aplicativos de log operacional. Um padrão de design comum nesses aplicativos é usar as alterações nos dados para disparar outras ações. Exemplos dessas ações incluem:

• Disparar uma notificação ou uma chamada a uma API quando um item é inserido, atualizado ou excluído.
• Processamento de fluxo em tempo real para IoT ou processamento de análise em tempo real em dados operacionais.
• Movimentação de dados, como a sincronização com um cache, um mecanismo de pesquisa, um data warehouse ou armazenamento frio.

O feed de alterações no Azure Cosmos DB permite que você crie soluções eficientes e escalonáveis para cada um desses padrões, conforme mostra a imagem a seguir:

Notificações e computação de eventos

O feed de alterações do Azure Cosmos DB pode simplificar os cenários que precisam disparar uma notificação ou enviar uma chamada a uma API com base em um determinado evento. Você pode usar o processador do feed de alterações para sondar automaticamente o contêiner em busca de alterações e chamar uma API externa sempre que houver uma gravação, atualização ou exclusão.

Você também pode disparar seletivamente uma notificação ou enviar uma chamada a uma API com base em critérios específicos. Por exemplo, se você estiver lendo do feed de alterações usando o Azure Functions, poderá colocar lógica na função para enviar uma notificação apenas se uma condição for atendida. Embora o código do Azure fosse executado em todas as alterações, a notificação só seria enviada se a condição fosse atendida.

Processamento de fluxo em tempo real

O feed de alterações do Azure Cosmos DB pode ser usado para processamento de fluxo em tempo real para IoT ou processamento de análise em tempo real em dados operacionais. Por exemplo, você pode receber e armazenar dados de evento de dispositivos, sensores, infraestrutura e aplicativos e, em seguida, processar esses eventos em tempo real usando o Spark. A imagem a seguir mostra como você pode implementar uma arquitetura lambda usando o feed de alterações do Azure Cosmos DB:

Em muitos casos, as implementações do processamento de fluxo recebem primeiro um alto volume de dados de entrada em uma fila de mensagens temporária como o Hub de Eventos do Azure ou o Apache Kafka. O feed de alterações é uma ótima alternativa devido à capacidade do Azure Cosmos DB de dar suporte a uma alta taxa sustentada de ingestão de dados com baixa latência de leitura e gravação garantida. As vantagens do feed de alterações do Azure Cosmos DB em uma fila de mensagens incluem:

Persistência de dados

Os dados gravados no Azure Cosmos DB aparecem no feed de alterações. Os dados são retidos no feed de alterações até que sejam excluídos se você ler usando o modo de versão mais recente. As filas de mensagens normalmente têm um período de retenção máximo. Por exemplo, os Hubs de Eventos do Azure oferecem uma retenção de dados máxima de 90 dias.

Capacidade de consulta

Além de ler do feed de alterações do contêiner do Azure Cosmos DB, você também pode executar consultas SQL nos dados armazenados no Azure Cosmos DB. O feed de alterações não é uma duplicação de dados que já estão no contêiner, mas apenas um mecanismo diferente de leitura dos dados. Portanto, se você ler os dados do feed de alterações, eles sempre serão consistentes com consultas do mesmo contêiner do Azure Cosmos DB.

Alta disponibilidade

O Azure Cosmos DB oferece até 99,999% de disponibilidade de leitura e gravação. Ao contrário de muitas filas de mensagens, os dados do Azure Cosmos DB podem ser distribuídos e configurados globalmente com um objetivo de tempo de recuperação (RTO) de zero.

Depois de processar itens no feed de alterações, você pode criar uma exibição materializada e manter os valores agregados de volta no Azure Cosmos DB. Se você estiver usando o Azure Cosmos DB para criar um jogo, poderá, por exemplo, usar o feed de alterações para implementar placares em tempo real de acordo com as pontuações de jogos concluídos.

Movimentação de dados

Você também pode ler no feed de alterações para uma movimentação de dados em tempo real.

Por exemplo, o feed de alterações ajuda você a executar as seguintes tarefas com eficiência:

• Atualizar um cache, índice de pesquisa ou data warehouse com dados armazenados no Azure Cosmos DB.

• Realizar migrações com tempo de inatividade zero para outra conta ou outro contêiner do Azure Cosmos DB com uma chave de partição lógica diferente.

• Implementar um arquivamento e uma camada de dados no nível do aplicativo. Por exemplo, você pode armazenar "dados de acesso frequente" no Azure Cosmos DB e envelhecer "dados frios" em outros sistemas de armazenamento, como o Armazenamento de Blobs do Azure.

Quando você precisa desnormalizar dados entre partições e contêineres, você pode ler o feed de alterações do seu contêiner como uma fonte para essa replicação de dados. A replicação de dados em tempo real com o feed de alterações só pode garantir a consistência eventual. Você pode monitorar o atraso do processador do feed de alterações no processamento de alterações do contêiner do Azure Cosmos DB.

Fornecimento de eventos

O padrão de fornecimento de evento envolve o uso de um armazenamento somente de acréscimo para registrar a série completa de ações nesses dados. O feed de alterações do Azure Cosmos DB é uma ótima opção como um armazenamento de dados central em arquiteturas de fornecimento de eventos em que toda a ingestão de dados é modelada como gravações (sem atualizações ou exclusões). Nesse caso, cada gravação no Azure Cosmos DB é um “evento”, o que significa que há um registro completo de eventos passados no feed de alterações. Usos típicos dos eventos publicados pelo repositório de eventos central se destinam a exibições materializadas ou para integração com sistemas externos. Como não há limite de tempo para a retenção no modo da versão mais recente do feed de alterações, você pode reproduzir todos os eventos anteriores lendo as informações do feed de alterações do contêiner do Azure Cosmos DB desde o início. Você pode até fazer vários consumidores do feed de alterações assinarem o feed de alterações do mesmo contêiner.

O Azure Cosmos DB é um ótimo armazenamento de dados central persistente somente de acréscimo no padrão de fornecimento de eventos devido aos seus pontos fortes em escalabilidade horizontal e alta disponibilidade. Além disso, o processador do feed de alterações oferece uma garantia “pelo menos uma vez” para que você não perca o processamento de nenhum evento.

Limitações atuais

O feed de alterações tem vários modos com limitações importantes que você deve entender. Há várias áreas a serem consideradas ao criar um aplicativo que usa o feed de alterações no modo de versão mais recente ou no modo todas as versões e exclusões.

Atualizações intermediárias

Modo de versão mais recente

No modo de versão mais recente, somente a alteração mais recente de um determinado item é incluída no feed de alterações. Ao processar alterações, você lê a versão mais recente do item disponível. Se houver várias atualizações do mesmo item em um curto período, será possível perder o processamento de atualizações intermediárias. Para reproduzir atualizações individuais anteriores em um item, você pode modelar essas atualizações como uma série de gravações ou usar o modo todas as versões e exclusões.

Modo Todas as versões e exclusões (versão prévia)

O modo todas as versões e exclusões fornece um log de operações completo de todas as versões do item em todas as operações. Nenhuma atualização intermediária será perdida se elas ocorrerem no período de retenção de backup contínuo configurado para a conta.

Deletes

Modo de versão mais recente

O modo de versão mais recente do feed de alterações não captura exclusões. Se você excluir um item do contêiner, ele também será removido do feed de alterações. O método mais comuns de lidar com exclusões é adicionar um marcador temporário nos itens que estão sendo excluídos. Você pode adicionar uma propriedade chamada deleted e defini-la como true no momento da exclusão. Essa atualização de documento é exibida no feed de alterações. Você pode definir uma TTL (vida útil) neste item para que ele possa ser excluído automaticamente mais tarde.

Modo todas as versões e exclusões (versão prévia)

As exclusões são capturadas no modo todas as versões e exclusões sem a necessidade de definir um marcador de exclusão temporária. Você também obtém metadados que indicam se a exclusão foi de uma expiração de TTL.

Retenção

Modo de versão mais recente

O feed de alterações no modo de versão mais recente tem uma retenção ilimitada. Desde que exista um item no contêiner, ele estará disponível no feed de alterações.

Modo todas as versões e exclusões (versão prévia)

No modo todas as versões e exclusões você pode ler somente as alterações que ocorreram no período de retenção de backup contínuo configurado para conta. Se a sua conta estiver configurada com um período de retenção de sete dias, você não conseguirá ler as alterações de oito dias atrás. Se o aplicativo precisa acompanhar todas as atualizações desde o início do contêiner, o modo de versão mais recente talvez seja mais adequado.

Ordem garantida

Todos os modos do feed de alterações têm uma ordem garantida no valor da chave de partição, mas não entre valores de chave de partição. Você deve selecionar uma chave de partição que ofereça uma garantia de ordem significativa.

Por exemplo, considere um aplicativo de varejo usando o padrão de design de fornecimento de eventos. Neste aplicativo, diferentes ações de usuário são “eventos” que são modelados como gravações no Azure Cosmos DB. Imagine se alguns eventos de exemplo ocorreram na seguinte sequência:

1. O cliente adicionar o item A ao carrinho de compras.
2. O cliente adiciona o item B ao carrinho de compras.
3. O cliente remove o item A do carrinho de compras.
4. O cliente faz check-out e o conteúdo do carrinho de compras é enviado.

Uma exibição materializada do conteúdo atual do carrinho de compras é mantida para cada cliente. Esse aplicativo deve verificar se esses eventos são processados na ordem em que ocorrem. Por exemplo, se o check-out do carrinho fosse processado antes da remoção do item A, provavelmente o item A seria enviado ao cliente em vez do item desejado pelo cliente, o item B. Para garantir que esses quatro eventos sejam processados na ordem da ocorrência, eles devem estar no mesmo valor da chave de partição. Se você selecionar username (cada cliente tem um nome de usuário exclusivo) como a chave de partição, poderá garantir que esses eventos apareçam no feed de alterações na mesma ordem em que forem gravados no Azure Cosmos DB.

Exemplos

Aqui estão alguns exemplos reais de código do feed de alterações no modo de versão mais recente que vão além do escopo dos exemplos fornecidos:

• Introdução ao feed de alterações
• Caso de uso de IoT centrado no feed de alterações
• Caso de uso de varejo centrado no feed de alterações

Próximas etapas

• Examine a visão geral do feed de alterações.
• Saiba mais sobre os modos do feed de alterações.
• Conheça suas opções para ler o feed de alterações.
• Tentando fazer o planejamento da capacidade para uma migração para o Azure Cosmos DB? Você pode usar informações sobre o cluster de banco de dados existente para fazer isso.
  • Se você conhece apenas o número de vCores e servidores do cluster de banco de dados existente, leia sobre como estimar unidades de solicitação com vCores ou vCPUs.
  • Se você conhece as taxas de solicitação típicas da sua carga de trabalho de banco de dados atual, leia sobre como estimar as unidades de solicitação usando o planejador de capacidade do Azure Cosmos DB.