Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O feed de alterações do Azure Cosmos DB permite processar com eficiência grandes conjuntos de dados com grandes 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 escaloná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 as alterações nos dados para disparar outras ações. Essas ações incluem:
- Disparar uma notificação ou chamar uma API quando um item for inserido, atualizado ou excluído.
- Processamento de fluxo em tempo real para IoT ou análise 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 escalonáveis para esses padrões, conforme mostrado na imagem a seguir:
Notificações e computação de eventos
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 do feed de alterações para sondar automaticamente o contêiner em busca de alterações e chamar uma API externa para cada gravação, atualização ou exclusão.
Dispare seletivamente uma notificação ou chame uma API com base em critérios específicos. Por exemplo, se você estiver lendo do 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 será enviada somente se a condição for atendida.
Processamento de fluxo em tempo real
O feed de alterações do Azure Cosmos DB permite que você execute o processamento de fluxo em tempo real para IoT ou análise 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 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.
Persistência de dados
Os dados gravados no Azure Cosmos DB são exibidos no feed de alterações. No modo última versão, os dados permanecem no feed de alterações até a exclusão. As filas de mensagens geralmente 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 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 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 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 globalmente e configurados com um RTO (objetivo de tempo de recuperação) de zero.
Depois de processar itens no feed de alterações, crie uma exibição materializada e persista valores agregados novamente no Azure Cosmos DB. Por exemplo, use o feed de alterações do Azure Cosmos DB para implementar placares de líderes em tempo real com base em pontuações de jogos concluídos.
Movimentação de dados
Leia no feed de alterações para movimentação de dados em tempo real.
Por exemplo, o feed de alterações permite que você execute as seguintes tarefas com eficiência:
Atualizar um cache, índice de pesquisa ou data warehouse com os 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.
Implemente a camada e o arquivamento de dados no nível do aplicativo. Por exemplo, armazene "dados de acesso frequente" no Azure Cosmos DB e transfira "dados de acesso esporádico" para 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 garante apenas consistência eventual. Você pode monitorar o quanto o processador do feed de alterações está atrasado no processamento de alterações do contêiner do Azure Cosmos DB.
Fonte de 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 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 central de eventos são manter visões materializadas ou integrar-se com sistemas externos. Como não há um limite de tempo para retenção no modo última versão do feed de alterações, você pode reproduzir todos os eventos passados lendo desde o início do feed de alterações do contêiner do Azure Cosmos DB. 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 excelente repositório de dados persistentes somente acréscimo central no padrão de fornecimento de eventos devido a seus pontos fortes na escalabilidade horizontal e alta disponibilidade. Além disso, o processador do feed de alterações oferece uma garantia "pelo menos uma vez", garantindo que você não perca o processamento de eventos.
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 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
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 passadas em um item, modele essas atualizações como uma série de gravações ou use todas as versões e modo de exclusões.
Exclusões
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 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.
Retention
O feed de alterações no modo de última versão tem retenção ilimitada. Desde que exista um item no contêiner, 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 valores de chave de partição. Você deve selecionar uma chave de partição que garanta uma ordem significativa.
Considere um aplicativo de varejo que usa o padrão de design de fornecimento de eventos. Nesse 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:
- O cliente adiciona o item A ao carrinho de compras.
- O cliente adiciona o item B ao 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 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 deve ser processado antes da remoção do Item A, é provável que o Item A tenha sido enviado ao cliente em vez do Item B desejado pelo cliente. Para garantir que esses quatro eventos sejam processados em ordem, eles devem se enquadrar no 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 forem gravados no Azure Cosmos DB.
Exemplos
Aqui estão exemplos de código do 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:
- Saiba mais em Introdução ao feed de alterações.
- Saiba mais no caso de uso de IoT centralizado em torno do feed de alterações.
- Saiba mais no caso de uso do Varejo centralizado em torno do feed de alterações.