Práticas recomendadas para trabalhar com a Integração ETL zero do DynamoDB e o OpenSearch Service

Somente indexe os dados nos quais você precisa realizar pesquisas. Sempre use um modelo de mapeamento (template_type: index_template e template_content) e include_keys para implementar isso.

Monitore os logs em busca de erros relacionados a conflitos de tipos. O OpenSearch Service espera que todos os valores de uma chave específica tenham o mesmo tipo. Ele gera exceções quando há incompatibilidades. Se você encontrar um desses erros, poderá adicionar um processador para conferir se uma chave específica sempre tem o mesmo valor.

Geralmente, use o valor de metadados primary_key para o valor document_id. No OpenSearch Service, o ID do documento é equivalente à chave primária no DynamoDB. O uso da chave primária facilitará a localização do documento e garantirá que as atualizações sejam replicadas de forma consistente e sem conflitos.

É possível usar a função auxiliar getMetadata para ter a chave primária (por exemplo, document_id: "${getMetadata('primary_key')}"). Se você estiver usando uma chave primária composta, a função auxiliar as concatenará para você.

Em geral, use o valor de metadados opensearch_action para a configuração action. Isso garantirá que as atualizações sejam replicadas de forma que os dados no OpenSearch Service correspondam ao estado mais recente no DynamoDB.

É possível usar a função auxiliar getMetadata para ter a chave primária (por exemplo, action: "${getMetadata('opensearch_action')}"). Também é possível ter o tipo de evento de fluxos por meio de dynamodb_event_name para casos de uso como filtragem. No entanto, normalmente, você não deve usá-lo para a configuração action.

Sempre use uma fila de mensagens não entregues (DLQ) em seus coletores do OpenSearch para lidar com eventos descartados. O DynamoDB geralmente é menos estruturado do que o OpenSearch Service, e sempre é possível que algo inesperado aconteça. Com uma fila de mensagens não entregues, é possível recuperar eventos individuais e até mesmo automatizar o processo de recuperação. Isso ajudará você a evitar a necessidade de recriar todo o índice.

Sempre defina alertas de que o atraso na replicação não ultrapassa o valor esperado. Normalmente, é seguro presumir um minuto para que o alerta não seja muito ruidoso. Isso pode variar dependendo da intensidade do tráfego de gravação e das configurações da unidade de computação do OpenSearch (OCU) no pipeline.

Se o atraso na replicação ultrapassar 24 horas, o fluxo começará a descartar eventos e você terá problemas de precisão, a menos que faça uma recriação completa do índice.

Use o ajuste de escala automático para pipelines a fim de ajudar a aumentar ou reduzir a escala verticalmente das OCUs e melhor atender à workload.

Para tabelas de throughput provisionadas sem ajuste de escala automático, recomendamos configurar OCUs com base nas unidades de capacidade de gravação (WCUs) divididas por mil. Defina o mínimo como 1 OCU abaixo desse valor (mas pelo menos 1) e defina o máximo como pelo menos 1 OCU acima desse valor.

Para tabelas de throughput provisionadas sem ajuste de escala automático, recomendamos configurar OCUs com base nas WCUs divididas por 1.000. Defina o mínimo como 1 OCU abaixo do mínimo do DynamoDB e defina o máximo como pelo menos 1 OCU acima do máximo do DynamoDB.

Para tabelas de throughput sob demanda, recomendamos configurar OCUs com base em picos e vales típicos para unidades de solicitação de gravação por segundo. Talvez seja necessário calcular a média por um longo período, dependendo da agregação disponível para você. Defina o mínimo como 1 OCU abaixo do mínimo do DynamoDB e defina o máximo como pelo menos 1 OCU acima do máximo do DynamoDB.

Siga as práticas recomendadas para escalar os índices de destino do OpenSearch Service. Se os índices estiverem subescalados, isso diminuirá a ingestão do DynamoDB e poderá causar atrasos.