Leitura do feed de alterações do Azure Cosmos DB
APLICA-SE A: 
NoSQL
Você pode trabalhar com o feed de alterações do Azure Cosmos DB usando um modelo push ou um modelo pull. Com um modelo push, o processador de alimentação de alterações envia o trabalho para um cliente que tem lógica de negócios para processar esse trabalho. No entanto, a complexidade na verificação do trabalho e no estado de armazenamento do último trabalho processado é tratada dentro do processador de alimentação de alterações.
Com um modelo pull, o cliente tem que puxar o trabalho do servidor. O cliente, neste caso, não só tem lógica de negócios para processar o trabalho, mas também armazenar o estado para o último trabalho processado, lidar com o balanceamento de carga entre vários clientes processando o trabalho em paralelo e manipulando erros.
Ao ler o feed de alterações do Azure Cosmos DB, geralmente recomendamos o uso de um modelo de push porque você não precisará se preocupar com:
- Sondagem do feed de alterações para alterações futuras.
- Estado de armazenamento da última alteração processada. Se você estiver lendo a partir do processador de feed de alterações, o estado será armazenado automaticamente em um contêiner de concessão.
- Balanceamento de carga entre vários clientes consumindo alterações. Por exemplo, se um cliente não consegue acompanhar as alterações de processamento e outro tem capacidade disponível.
- Tratamento de erros. Por exemplo, repetir automaticamente as alterações com falha que não foram processadas corretamente após uma exceção não tratada no código ou um problema de rede transitório.
A maioria dos cenários que usam o feed de alterações do Azure Cosmos DB usará uma das opções do modelo de push. No entanto, há alguns cenários em que você pode querer o controle adicional de baixo nível do modelo pull. Estes são, entre outros:
- Alterações de leitura de uma chave de partição específica
- Controlar o ritmo a que o seu cliente recebe alterações para processamento
- Fazer uma leitura única dos dados existentes no feed de alterações (por exemplo, para fazer uma migração de dados)
Ler o feed de alterações com um modelo push
Usar um modelo push é a maneira mais fácil de ler a partir do feed de alterações. Há duas maneiras de ler o feed de alterações com um modelo push: Azure Functions Azure Cosmos DB triggers e o processador change feed. O Azure Functions usa o processador de feed de alterações nos bastidores, portanto, essas são maneiras semelhantes de ler o feed de alterações. Pense no Azure Functions como simplesmente uma plataforma de hospedagem para o processador de feed de alterações, não uma maneira totalmente diferente de ler o feed de alterações.
Funções do Azure
O Azure Functions é a opção mais simples se você estiver apenas começando a usar o feed de alterações. Devido à sua simplicidade, é também a opção recomendada para a maioria dos casos de uso de feed de alterações. Ao criar um gatilho do Azure Functions para o Azure Cosmos DB, você seleciona o contêiner a ser conectado e o Azure Function é acionado sempre que há uma alteração no contêiner. Como o Azure Functions usa o processador de feed de alterações nos bastidores, ele paraleliza automaticamente o processamento de alterações nas partições do contêiner.
Desenvolver com o Azure Functions é uma experiência fácil e pode ser mais rápido do que implantar o processador de feed de alterações por conta própria. Os gatilhos podem ser criados usando o portal do Azure Functions ou programaticamente usando SDKs. O Visual Studio e o VS Code fornecem suporte para escrever o Azure Functions, e você pode até usar a CLI do Azure Functions para desenvolvimento entre plataformas. Você pode escrever e depurar o código em sua área de trabalho e, em seguida, implantar a função com um botão. Consulte os artigos Computação de banco de dados sem servidor usando o Azure Functions e Usando o feed de alterações com o Azure Functions para saber mais.
Alterar a biblioteca do processador de feed
SDKs suportados
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
O processador de feed de alterações oferece mais controle sobre o feed de alterações e ainda oculta a maior parte da complexidade. A biblioteca do processador de feed de alterações segue o padrão observador, onde sua função de processamento é chamada pela biblioteca. O processador de alimentação de alterações verificará automaticamente se há alterações e, se forem encontradas alterações, "enviá-las" para o cliente. Se você tiver um feed de alterações de alta taxa de transferência, poderá instanciar vários clientes para ler o feed de alterações. O processador de alimentação de alterações dividirá automaticamente a carga entre os diferentes clientes. Você não precisará implementar nenhuma lógica para balanceamento de carga em vários clientes ou qualquer lógica para manter o estado de concessão.
O processador de alimentação de alterações garante uma entrega "pelo menos uma vez" de todas as alterações. Em outras palavras, se você usar o processador de feed de alterações, sua função de processamento será chamada com êxito para cada item no feed de alterações. Se houver uma exceção não tratada na lógica de negócios em sua função de processamento, as alterações com falha serão repetidas até que sejam processadas com êxito. Para evitar que o processador de feed de alterações fique "preso" continuamente repetindo as mesmas alterações, adicione lógica na função de processamento para escrever documentos, mediante exceção, em uma fila de mensagens mortas. Saiba mais sobre o tratamento de erros.
No Azure Functions, a recomendação para lidar com erros é a mesma. Você ainda deve adicionar lógica em seu código de delegado para escrever documentos, mediante exceção, em uma fila de mensagens mortas. No entanto, se houver uma exceção não tratada em sua Função do Azure, a alteração que gerou a exceção não será repetida automaticamente. Se houver uma exceção não tratada na lógica de negócios, a Função do Azure passará a processar a próxima alteração. A Função do Azure não tentará novamente a mesma alteração com falha.
Como o Azure Functions, desenvolver com a biblioteca do processador de feed de alterações é fácil. No entanto, você é responsável por implantar um ou mais hosts para o processador de feed de alterações. um anfitrião é uma instância de aplicação que utiliza o processador do feed de alterações para escutar as alterações. Embora o Azure Functions tenha recursos para dimensionamento automático, você é responsável pelo dimensionamento de seus hosts. Para saber mais, consulte Usando o processador de feed de alterações. A biblioteca do processador de feed de alterações faz parte do SDK do Azure Cosmos DB V3.
Leitura do feed de alterações com um modelo pull
O modelo de pull de feed de mudança permite que você consuma o feed de mudança no seu próprio ritmo. As alterações devem ser solicitadas pelo cliente e não há sondagem automática para alterações. Se quiser "marcar" permanentemente a última alteração processada (semelhante ao contêiner de locação do modelo push), será necessário salvar um token de continuação.
Usando o modelo de pull de feed de alterações, você obtém um controle de nível mais baixo do feed de alterações. Ao ler o feed de alterações com o modelo pull, você tem três opções:
- Ler alterações para um contêiner inteiro
- Ler alterações para um FeedRange específico
- Ler alterações para um valor de chave de partição específico
Você pode paralelizar o processamento de alterações em vários clientes, assim como pode fazer com o processador de feed de alterações. No entanto, o modelo pull não lida automaticamente com o balanceamento de carga entre clientes. Ao usar o modelo pull para paralelizar o processamento do feed de alterações, você obterá primeiro uma lista de FeedRanges. Um FeedRange abrange um intervalo de valores de chave de partição. Você precisará ter um processo orquestrador que obtenha FeedRanges e os distribua entre suas máquinas. Em seguida, você pode usar esses FeedRanges para que várias máquinas leiam o feed de alterações em paralelo.
Não há garantia de entrega "pelo menos uma vez" integrada com o modelo pull. O modelo pull oferece controle de baixo nível para decidir como você gostaria de lidar com erros.
Alterar feed em APIs para Cassandra e MongoDB
A funcionalidade de feed de alteração é apresentada como fluxos de alteração na API para MongoDB e Query com predicado na API para Cassandra. Para saber mais sobre os detalhes de implementação da API para MongoDB, consulte Change streams no Azure Cosmos DB for MongoDB.
O Apache Cassandra nativo fornece captura de dados de alteração (CDC), um mecanismo para sinalizar tabelas específicas para arquivamento e rejeição de gravações nessas tabelas assim que um tamanho configurável no disco para o log CDC é alcançado. O recurso de feed de alterações no Azure Cosmos DB para Apache Cassandra aprimora a capacidade de consultar as alterações com predicado via CQL. Para saber mais sobre os detalhes da implementação, consulte Alterar feed no Azure Cosmos DB para Apache Cassandra.
Próximos passos
Agora você pode continuar a saber mais sobre o feed de alterações nos seguintes artigos: