Alterar padrões de design de feed 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 com um grande volume de gravações. O feed de alterações também oferece uma alternativa para consultar um conjunto de dados inteiro para identificar o que mudou. Este artigo se concentra em padrões comuns de design de feed de alterações, compensações de design e limitações de 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 alterações nos dados para acionar outras ações. Exemplos dessas ações incluem:

• Disparar uma notificação ou uma chamada para uma API quando um item é inserido, atualizado ou excluído.
• Processamento de fluxo em tempo real para IoT ou processamento analítico em tempo real em dados operacionais.
• Movimentação de dados, como 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 criar soluções eficientes e escaláveis para cada um desses padrões, conforme mostrado na imagem a seguir:

Computação de eventos e notificações

O feed de alterações do Azure Cosmos DB pode simplificar cenários que precisam disparar uma notificação ou enviar uma chamada para uma API com base em um determinado evento. Você pode usar o processador de feed de alterações para sondar automaticamente seu contêiner em busca de alterações e, em seguida, 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 para uma API com base em critérios específicos. Por exemplo, se você estiver lendo o feed de alterações usando o Azure Functions, poderá colocar lógica na função para enviar uma notificação somente se uma condição for atendida. Embora o código da Função do Azure seja executado para cada alteração, a notificação será enviada somente se a condição for 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 eventos 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 de processamento de fluxo recebem primeiro um grande volume de dados de entrada em uma fila de mensagens temporária, como Hubs de Eventos do Azure ou Apache Kafka. O feed de alterações é uma ótima alternativa devido à capacidade do Azure Cosmos DB de oferecer 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é serem excluídos se você ler usando o modo de versão mais recente. As filas de mensagens normalmente têm um período máximo de retenção. Por exemplo, os Hubs de Eventos do Azure oferecem uma retenção máxima de dados de 90 dias.

Capacidade de consulta

Além de ler a partir do feed de alterações de um contêiner do Azure Cosmos DB, você 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 sim um mecanismo diferente de leitura dos dados. Portanto, se você ler dados do feed de alterações, os dados serão sempre consistentes com consultas do mesmo contêiner do Azure Cosmos DB.

Elevada 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 facilmente distribuídos globalmente e configurados com um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de zero.

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

Movimento de dados

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

Por exemplo, o feed de alterações ajuda você a executar as seguintes tarefas de forma eficiente:

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

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

• Implemente uma hierarquização e arquivamento de dados no nível do aplicativo. Por exemplo, você pode armazenar "dados quentes" no Azure Cosmos DB e eliminar "dados frios" para outros sistemas de armazenamento, como o Armazenamento de Blobs do Azure.

Quando você precisa desnormalizar dados entre partições e contêineres, pode ler o feed de alterações do 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 pode garantir apenas uma eventual consistência. Você pode monitorar até que ponto o processador de feed de alterações está atrasado no processamento de alterações em seu contêiner do Azure Cosmos DB.

Origem dos eventos

O padrão de fornecimento de eventos envolve o uso de um armazenamento somente 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 armazenamento de dados central em arquiteturas de fornecimento de eventos nas quais 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", portanto, há um registro completo de eventos anteriores no feed de alterações. Os usos típicos dos eventos publicados pela loja central de eventos são para manter visualizações materializadas ou para integrar com sistemas externos. Como não há limite de tempo para retenção no modo de versão mais recente do feed de alterações, você pode repetir todos os eventos anteriores lendo desde o início do feed de alterações do contêiner do Azure Cosmos DB. Você pode até mesmo fazer com que vários consumidores de feed de alterações assinem o feed de alterações do mesmo contêiner.

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

Limitações atuais

O feed de alterações tem vários modos que cada um tem 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 em todas as versões e exclui.

Atualizações intermediárias

Eliminações

Retenção

Ordem garantida

Todos os modos de alimentação de alteração têm uma ordem garantida dentro de um valor de chave de partição, mas não entre valores de chave de partição. Você deve selecionar uma chave de partição que lhe dê uma garantia de ordem significativa.

Por exemplo, considere um aplicativo de varejo que usa o padrão de design de fornecimento de eventos. Neste aplicativo, diferentes ações do usuário são cada "evento", 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 adiciona o Item A ao seu carrinho de compras.
2. O Cliente adiciona o Item B ao seu 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 visão materializada do conteúdo atual do carrinho de compras é mantida para cada cliente. Este aplicativo deve garantir que esses eventos sejam processados na ordem em que ocorrem. Por exemplo, se o checkout do carrinho fosse processado antes da remoção do Item A, é provável que o Item A tivesse sido enviado para o cliente, e não o item que o cliente queria, o Item B. Para garantir que esses quatro eventos sejam processados na ordem de sua ocorrência, eles devem estar dentro do mesmo valor de 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 são gravados no Azure Cosmos DB.

Exemplos

Aqui estão alguns exemplos de código de feed de alterações do mundo real para o 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

Conteúdos relacionados

• Visão geral do feed de alterações
• Alterar modos de alimentação
• Opções para ler o feed de alterações