Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O feed de alterações do Azure Cosmos DB permite processar com eficiência grandes conjuntos de dados com altos volumes de gravação. Ele fornece uma alternativa para consultar conjuntos de dados inteiros para identificar alterações. Este artigo explica padrões comuns de design de feed de alterações, suas compensações e limitações para ajudá-lo a criar soluções escaláveis.
Cenários
O Azure Cosmos DB é ideal 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. Estas 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 análise de dados operacionais.
- Movimentação de dados, como sincronização com um cache, um motor de busca, um armazém de dados ou armazenamento arquivado.
O feed de alterações no Azure Cosmos DB permite criar soluções eficientes e escaláveis para esses padrões, conforme mostrado na imagem a seguir:
Computação de eventos e notificações
O feed de alterações do Azure Cosmos DB simplifica cenários que disparam uma notificação ou chamam uma API com base em um evento específico. Use o processador de feed de alterações para pesquisar automaticamente o contêiner em busca de alterações e chamar uma API externa para cada gravação, atualização ou exclusão.
Acione seletivamente uma notificação ou chame uma API com base em critérios específicos. Por exemplo, se você estiver lendo o feed de alterações usando o Azure Functions, adicione lógica à 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 é enviada somente se a condição for atendida.
Processamento de fluxo em tempo real
O feed de alterações do Azure Cosmos DB permite executar processamento de fluxo em tempo real para IoT ou análises em tempo real em dados operacionais. Por exemplo, você recebe e armazena dados de eventos de dispositivos, sensores, infraestrutura e aplicativos e processa esses eventos em tempo real usando o Spark. A imagem a seguir mostra como 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.
Persistência de dados
Os dados gravados no Azure Cosmos DB aparecem no feed de alterações. No modo de versão mais recente, os dados permanecem no feed de alterações até a exclusão. As filas de mensagens geralmente 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 o feed de alterações de um contêiner do Azure Cosmos DB, execute 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.
Alta disponibilidade
O Azure Cosmos DB fornece até 99.999% 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 RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de zero.
Depois de processar itens no feed de alterações, crie uma exibição materializada e persista os valores agregados de volta no Azure Cosmos DB. Por exemplo, use o feed de alterações do Azure Cosmos DB para implementar tabelas de classificação em tempo real com base nas pontuações de jogos concluídos.
Movimentação de dados
Leia a partir do feed de alterações para movimentação de dados em tempo real.
Por exemplo, o feed de alterações permite 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 a hierarquização e o arquivamento de dados no nível do aplicativo. Por exemplo, armazene "dados quentes" no Azure Cosmos DB e libere "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 garante 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 usa um repositório somente acréscimo para registrar a série completa de ações nos 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á um limite de tempo para retenção no modo de versão mais recente do feed de alterações, você pode reproduzir 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 excelente armazenamento de dados persistente de acréscimo central 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, cada um com limitações importantes que você deve entender. Há várias áreas a considerar ao desenhar uma aplicação que usa a feed de alterações no modo de versão mais recente ou no modo de todas as versões e eliminações.
Atualizações intermediárias
No modo de versão mais recente, apenas a alteração mais recente para um item específico é 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 para o mesmo item em um curto período de tempo, é possível perder o processamento de atualizações intermediárias. Para reproduzir atualizações individuais anteriores de um item, modele essas atualizações como uma série de gravações ou use todas as versões e o modo de exclusão.
Elimina
O modo de versão mais recente do feed de alterações não captura exclusões. Quando você exclui um item do contêiner, o item é removido do feed de alterações. O método mais comum para lidar com operações de exclusão é adicionar um marcador suave aos itens que estão sendo excluídos. Você pode adicionar uma propriedade chamada deleted e defini-la no true momento da exclusão. Esta atualização de documento aparece no feed de alterações. Você pode definir um tempo de vida (TTL) neste item para que ele possa ser excluído automaticamente mais tarde.
Retenção
O fluxo de alterações no modo de última versão tem retenção ilimitada. Desde que exista um item no seu recipiente, ele estará disponível no feed de alterações.
Ordem garantida
Todos os modos de feed de alterações têm uma ordem garantida dentro de um valor de chave de partição, mas não entre diferentes valores de chave de partição. Você deve selecionar uma chave de partição que lhe dê uma garantia de ordem significativa.
Considere um aplicativo de varejo que use o padrão de design de fornecimento de eventos. Neste aplicativo, cada ação do usuário é considerada um "evento", modelado como uma gravação no Azure Cosmos DB. Imagine se alguns eventos de exemplo ocorreram na seguinte sequência:
- O cliente adiciona o Item A ao seu carrinho de compras.
- O Cliente adiciona o Item B ao seu carrinho de compras.
- O cliente remove o Item A do carrinho de compras.
- 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 fosse enviado para o cliente em vez do Item B que o cliente queria. Para garantir que esses quatro eventos sejam processados em ordem, 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.
Examples
Aqui estão exemplos de código de feed de alteração do mundo real para o modo de versão mais recente que vão além do escopo dos exemplos fornecidos:
- Saiba mais em Introdução ao feed de alterações.
- Saiba mais em Caso de uso de IoT centrado no feed de alterações.
- Saiba mais em Caso de uso de varejo centrado no feed de alterações.