Prácticas recomendadas para trabajar con la integración sin ETL de DynamoDB y OpenSearch Service

DynamoDB dispone de una integración sin ETL de DynamoDB con Amazon OpenSearch Service. Para obtener más información, consulte el complemento de DynamoDB para OpenSearch Ingestion y las prácticas recomendadas específicas para Amazon OpenSearch Service.

Configuración

• Indexe únicamente los datos en los que tenga que realizar búsquedas. Utilice siempre una plantilla de asignación (template_type: index_template y template_content) y include_keys para implementarla.

• Monitoree los registros para detectar errores relacionados con conflictos con los tipos. OpenSearch Service espera que todos los valores de una clave determinada sean del mismo tipo. Si hay alguna discrepancia, genera excepciones. Si se topa con alguno de estos errores, puede añadir un procesador para detectar que una clave determinada tenga siempre el mismo valor.

• De forma general, utilice el valor de los metadatos primary_key para el valor document_id. En OpenSearch Service, el ID del documento equivale a la clave principal de DynamoDB. Al usar la clave principal es más sencillo buscar el documento y garantizar que las actualizaciones se repliquen en él de forma coherente y sin conflictos.

  Puede usar la función auxiliar getMetadata para obtener la clave principal (por ejemplo, document_id: "${getMetadata('primary_key')}"). Si utiliza una clave primaria compuesta, la función auxiliar las concatenará automáticamente.

• Se recomienda utilizar el valor de los metadatos opensearch_action para la configuración action. De este modo se garantiza que las actualizaciones se repliquen de forma que los datos de OpenSearch Service coincidan con el estado más reciente de DynamoDB.

  Puede usar la función auxiliar getMetadata para obtener la clave principal (por ejemplo, action: "${getMetadata('opensearch_action')}"). También puede usar el tipo de evento de secuencia mediante dynamodb_event_name para casos de uso como el filtrado. Sin embargo, no debería usarlo para la configuración action.

Observabilidad

• Utilice siempre una cola de mensajes fallidos (DLQ) en los receptores de OpenSearch para gestionar los eventos eliminados. DynamoDB suele estar menos estructurado que OpenSearch Service, por lo que es posible que ocurra algo inesperado. Las colas de mensajes fallidos permiten recuperar eventos individuales e incluso automatizar el proceso de recuperación. De este modo, se evita tener que reconstruir todo el índice.

• Establezca siempre alertas para indicar que el retardo en la replicación no supere un valor esperado. Por lo general, es prudente prever un minuto sin que la alerta sea demasiado escandalosa. Esto puede variar en función del pico del tráfico de escritura y de la configuración de la unidad de computación de OpenSearch (OCU) en la canalización.

  Si el retardo en la replicación es superior a 24 horas, la secuencia empezará a eliminar eventos y tendrá problemas de precisión, a menos que reconstruya completamente el índice desde cero.

Escalado

• Utilice el escalado automático para las canalizaciones a fin de escalar o reducir verticalmente las OCU para que se adapten mejor a la carga de trabajo.

• Para las tablas de rendimiento aprovisionadas sin escalado automático, recomendamos configurar las OCU en función de la cantidad de unidades de capacidad de escritura (WCU) dividida entre 1000. Establezca el valor mínimo en 1 OCU por debajo de esa cantidad (pero al menos 1) y defina el valor máximo en al menos 1 OCU por encima de esa cantidad.

  • Fórmula:

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

  • Ejemplo: La tabla tiene 25 000 WCU aprovisionadas. Las OCU de su canalización deben configurarse con un valor mínimo de 24 (25 000/1000 - 1) y un valor máximo de 26 (25 000/1000 + 1).

• Para las tablas de rendimiento aprovisionadas con escalado automático, recomendamos configurar las OCU en función de las cantidades mínima y máxima de WCU divididas entre 1000. Establezca el valor mínimo en 1 OCU por debajo del valor mínimo de DynamoDB y defina el valor máximo en al menos 1 OCU por encima del valor máximo de DynamoDB.

  • Fórmula:

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

  • Ejemplo: La tabla tiene una política de escalado automático con un valor mínimo de 8000 y un valor máximo de 14 000. Las OCU de su canalización deben configurarse con un valor mínimo de 7 (8000/1000 - 1) y un valor máximo de 15 (14 000/1000 + 1).

• Para las tablas de rendimiento bajo demanda, recomendamos configurar las OCU en función del pico y el valle típicos para las unidades de solicitud de escritura por segundo. Es posible que tenga que calcular una media de un período de tiempo más largo, en función de la agregación disponible. Establezca el valor mínimo en 1 OCU por debajo del valor mínimo de DynamoDB y defina el valor máximo en al menos 1 OCU por encima del valor máximo de 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

  • Ejemplo: La tabla tiene un valor medio de 300 unidades de solicitud de escritura por segundo y un pico medio de 4300. Las OCU de su canalización deben configurarse con un valor mínimo de 1 (300/1000 - 1, pero al menos 1) y un valor máximo de 5 (4300/1000 + 1).

• Siga las prácticas recomendadas para escalar los índices de OpenSearch Service de destino. Si los índices no se han escalado suficientemente, se ralentizará la ingesta desde DynamoDB y se podrían generar retardos.

nota

GREATEST es una función de SQL que devuelve el argumento con el valor más alto según un conjunto de argumentos determinado.