Práticas recomendadas para integração com o DynamoDB

Ao integrar o DynamoDB a outros serviços, é necessário sempre seguir as práticas recomendadas para usar cada serviço. No entanto, há algumas práticas recomendadas específicas de integração nas quais você deve pensar.

Criar um snapshot no DynamoDB

• Em geral, recomendamos o uso da exportação para o Amazon S3 para criar snapshots da replicação inicial. É econômico e não concorrerá com o tráfego da aplicação em termos de throughput. Também é possível pensar em backup e restauração em uma nova tabela, seguidos de uma operação de verificação. Isso evitará a disputa por throughput com sua aplicação, mas geralmente será consideravelmente menos econômico do que uma exportação.

• Sempre defina StartTime ao fazer uma exportação. Isso facilita a determinação de onde você iniciará a captura de dados de alteração (CDC).

• Ao usar a exportação para o S3, defina uma ação de ciclo de vida no bucket do S3. Normalmente, uma ação de expiração definida em sete dias é segura, mas é necessário seguir todas as diretrizes que a empresa possa ter. Mesmo que você exclua explicitamente os itens após a ingestão, essa ação pode ajudar a detectar problemas e, portanto, reduzir custos desnecessários e evitar violações de política.

Capturar alterações de dados no DynamoDB

• Se você precisar de uma CDC quase em tempo real, use o DynamoDB Streams ou o Amazon Kinesis Data Streams (KDS). Ao decidir qual deles usar, procure sempre pensar em qual é o mais fácil de usar com o serviço subsequente. Se você precisar fornecer processamento de eventos em ordem em nível de chave de partição ou se tiver itens excepcionalmente grandes, use o DynamoDB Streams.

• Se não precisar de CDC quase em tempo real, poderá usar a exportação para o Amazon S3 com exportações incrementais para exportar somente as alterações que ocorreram entre dois momentos.

  Se você usou a exportação para o S3 para gerar um snapshot, isso pode ser especialmente útil porque é possível usar um código semelhante para processar exportações incrementais. Normalmente, a exportação para o S3 é um pouco mais barata do que as opções de streaming anteriores, mas o custo normalmente não é o principal fator para a opção a ser usada.

• Geralmente, só é possível ter dois consumidores simultâneos de um fluxo do DynamoDB. Pense nisso ao planejar a estratégia de integração.

• Não use verificações para detectar alterações. Isso pode funcionar em pequena escala, mas se torna impraticável de modo razoavelmente rápido.

Integração ETL zero do DynamoDB com o OpenSearch Service

O DynamoDB tem uma integração ETL zero do DynamoDB com o Amazon OpenSearch Service. Para ter mais informações, consulte o plug-in do DynamoDB para ingestão do OpenSearch e as práticas recomendadas específicas para o Amazon OpenSearch Service.

Configuração

• 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.

Observabilidade

• 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.

Escalabilidade

• 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.

  • Fórmula:

    OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
    OCU_maximum = (table_WCU / 1000) + 1

  • Exemplo: sua tabela tem 25.000 WCUs provisionadas. As OCUs do pipeline devem ser definidas com um mínimo de 24 (25.000/1.000 - 1) e máximo de pelo menos 26 (25.000/1.000 + 1).

• 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.

  • Fórmula:

    OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
    OCU_maximum = (table_maximum_WCU / 1000) + 1

  • Exemplo: sua tabela tem uma política de ajuste de escala automático com um mínimo de 8.000 e máximo de 14.000. As OCUs do pipeline devem ser definidas com um mínimo de 7 (8.000/1.000 - 1) e um máximo de 15 (14.000/1.000 + 1).

• 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.

  • Fórmula:

    # Assuming we have writes aggregated at the minute level
    OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
    OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1

  • Exemplo: sua tabela tem um vale médio de 300 unidades de solicitação de gravação por segundo e um pico médio de 4.300. As OCUs do pipeline devem ser definidas com um mínimo de 1 (300/1.000 - 1, mas pelo menos 1) e máximo de 5 (4.300/1.000 + 1).

• 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.

nota

GREATEST é uma função SQL que, considerando-se um conjunto de argumentos, exibe o argumento com o maior valor.