Atlas Triggers
Nesta página
Gatilhos do Atlas executam a lógica do aplicativo e do banco de dados. Os gatilhos podem responder a eventos ou usar agendas predefinidas.
Os triggers escutam eventos de um tipo configurado. Cada trigger está vinculado a uma função do Atlas específica. Quando um trigger observa um evento que corresponde à sua configuração, ele "dispara". O trigger passa esse objeto de evento como argumento para sua Função vinculada.
Um gatilho pode acionar em:
Um tipo de operação específico em uma determinada Coleção.
Um horário programado.
O Atlas acompanha o tempo de execução mais recente de cada trigger e garante que cada evento seja processado pelo menos uma vez.
Tipos de Gatilho
O Atlas é compatível com estes tipos de trigger:
Os gatilhos do banco de dados respondem à inserção, alteração ou exclusão de documentos. Você pode configurar gatilhos de banco de dados para cada coleção vinculada do MongoDB.
Gatilhos programados executam funções de acordo com um cronograma predefinido.
Limitações
Aplicam-se Restrições da Função Atlas
Os gatilhos invocam funções do Atlas Function. Isso significa que elas têm as mesmas restrições que todas as Atlas Functions.
Saiba mais sobre restrições de Atlas Function.
Taxa de Transferência de Processamento de Evento
Aciona eventos de processo quando a capacidade fica disponível. A capacidade de um gatilho é determinada pela configuração do pedido do evento:
Os gatilhos ordenados processam eventos do fluxo de alterações, um de cada vez, em sequência. O próximo evento começa a ser processado somente após o término do processamento do evento anterior.
Os triggers não ordenados podem processar vários eventos simultaneamente, até 10.000 de uma vez por padrão. Se sua fonte de dados de triggers for um Atlas cluster M10+, você poderá configurar triggers individuais não ordenados para exceder o limite de 10.000 eventos simultâneos. Para saber mais, consulte Triggers de taxa de transferência máxima.
A capacidade do gatilho não é uma medida direta de rendimento ou uma taxa de execução garantida. Em vez disso, é um limite para o número máximo de eventos que um gatilho pode processar de uma vez. Na prática, a taxa na qual um Gatilho pode processar eventos depende da lógica de tempo de execução da função Gatilho e do número de eventos que ele recebe em um determinado período de tempo.
Para aumentar o rendimento de um Trigger, você pode tentar:
Otimize o comportamento de tempo de execução da função do Gatilho. Por exemplo, você pode reduzir o número de chamadas de rede que você faz.
Reduza o tamanho de cada objeto de evento com o filtro de projeção do gatilho. Para obter o melhor desempenho, limite o tamanho de cada evento de mudança para KB ou menos.
Usar um filtro de correspondência para reduzir o número de eventos que os Triggers processam. Por exemplo, você pode querer fazer algo somente se um campo específico for alterado. Em vez de corresponder a cada evento de atualização e verificar se o campo foi alterado em seu código de função, você pode usar o filtro de correspondência do trigger para acionar somente se o campo estiver incluído no objeto
updateDescription.updatedFieldsdo evento.
O Número de Gatilhos Não Pode Exceder os Fluxos de Mudança Disponíveis
O Atlas limita o número total de gatilhos de banco de dados. O tamanho do seu cluster Atlas determina esse limite.
Cada camada de cluster do Atlas tem um número máximo de fluxos de alteração suportados. Um gatilho de banco de dados exige seu próprio fluxo de alterações. Os Gatilhos do Banco de Dados podem não exceder o número de fluxos de alteração disponíveis.
Saiba mais sobre o número de fluxos de alterações compatíveis com as camadas do Atlas na página Limitações de serviço.
Diagnosticar eventos duplicados
Os triggers não emitem eventos duplicados durante o funcionamento normal. Contudo, em certas condições de falha ou erro, os triggers podem gerar eventos duplicados. Você pode observar um evento trigger duplicado quando:
Um servidor responsável por processar e rastrear eventos apresenta uma falha. Essa falha impede que o servidor registre seu progresso em um sistema de armazenamento durável ou de longo prazo, fazendo com que ele "esqueça" que processou alguns dos termos mais recentes.
Usando processamento não ordenado onde os eventos de 1 a 10 são enviados simultaneamente. Caso o evento 9 falhe e cause a suspensão do trigger, eventos como o evento 10 poderão ser reprocessados quando o sistema for retomado a partir do evento 9. Isso pode gerar duplicatas, pois o sistema não segue rigorosamente a sequência de eventos e pode reprocessar eventos que já foram processados.
Se você notar eventos trigger de duplicados, verifique se trigger há suspensos ou falhas no servidor .