Prácticas recomendadas para la integración con DynamoDB

Al integrar DynamoDB con otros servicios, debe seguir siempre las prácticas recomendadas sobre el uso de cada servicio. Además, debe tener en cuenta algunas prácticas recomendadas específicas de la integración.

Creación de una instantánea en DynamoDB

• En general, recomendamos utilizar la exportación a Amazon S3 para crear instantáneas para la replicación inicial. Esta opción es rentable y no competirá por el rendimiento con el tráfico de su aplicación. Otra opción es realizar una copia de seguridad, restaurarla en una nueva tabla y finalizar con una operación de análisis. Esto evitará que se compita por el rendimiento con la aplicación, aunque, por lo general, será considerablemente menos rentable que una exportación.

• Defina siempre una StartTime al exportar. De este modo, será más fácil determinar dónde debe empezar la captura de datos de cambios (CDC).

• Si utiliza la exportación a S3, establezca una acción de ciclo de vida en el bucket de S3. Por lo general, establecer una acción con una caducidad de siete días es seguro, pero debe seguir las pautas definidas por su empresa. Incluso si elimina los elementos de forma explícita después de la ingesta, esta acción puede ayudar a detectar problemas. De este modo, se reduce cualquier costo innecesario y se evita cualquier infracción de las políticas.

Captura de datos de cambios en DynamoDB

• Si precisa una captura de datos de cambios (CDC) casi en tiempo real, utilice DynamoDB Streams o Amazon Kinesis Data Streams (KDS). A la hora de decidirse por una de las dos opciones, tenga en cuenta cuál es más fácil de usar con el servicio posterior. Si tiene que proporcionar un procesamiento de eventos ordenado en el nivel de la clave de partición, o si tiene unos elementos excepcionalmente grandes, utilice DynamoDB Streams.

• Si no necesita una CDC prácticamente en tiempo real, puede utilizar la exportación a Amazon S3 con exportaciones incrementales para exportar solo los cambios que se hayan producido entre dos momentos concretos.

  Si ha utilizado la exportación a S3 para generar una instantánea, puede resultar especialmente útil, ya que puede utilizar un código similar para procesar las exportaciones incrementales. Por lo general, la exportación a S3 es un poco más económica que las opciones de secuencia anteriores, pero a la hora de elegir una opción, el costo no suele ser el factor primordial.

• En general, solo puede haber dos consumidores simultáneos de una secuencia de DynamoDB. Tenga esto en cuenta a la hora de planificar su estrategia de integración.

• No utilice análisis para detectar cambios. Esto puede funcionar a pequeña escala, pero resulta ser poco práctico de forma bastante rápida.

Integración sin ETL de DynamoDB con 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.