1- Se ha superado el rendimiento del rango clave (particiones calientes)

Los límites de partición de DynamoDB y el diseño efectivo de claves de partición abordan la prevención de particiones calientes, consulte Prácticas recomendadas para diseñar y utilizar claves de partición de forma eficaz en DynamoDB.

Conceptos generales de partición y distribución de datos, consulte Particiones en DynamoDB.

Para obtener más información y escenarios reales para administrar las claves de partición y el rendimiento, consulte Recursos adicionales.

DynamoDB se adapta a menudo a las particiones calientes mediante su mecanismo automático de división por calor. Si ve que los eventos de limitación se detienen después de un breve periodo de tiempo, es posible que la tabla ya se haya adaptado al dividir la partición caliente. Cuando las particiones se dividen, cada nueva partición ocupa una sección más pequeña del espacio de claves, lo que puede ayudar a distribuir la carga de manera más uniforme. En muchos casos, no tiene que hacer nada más, ya que DynamoDB ha resuelto el problema automáticamente.

Para obtener más información sobre el mecanismo de división por calor, consulte Recursos adicionales.

TableReadKeyRangeThroughputExceeded

TableWriteKeyRangeThroughputExceeded

IndexReadKeyRangeThroughputExceeded

IndexWriteKeyRangeThroughputExceeded

Capacidad de precalentamiento: si la limitación persiste, compruebe si la tabla está limitada por su capacidad de Descripción del rendimiento en caliente de DynamoDB. Utilice un rendimiento en caliente o aumente la capacidad de lectura aprovisionada con antelación para los aumentos de tráfico esperados. Al aumentar el rendimiento en caliente, se mejora la capacidad de la tabla para gestionar picos de tráfico repentinos antes de que se produzca una limitación. Con el tiempo, si el rendimiento real se aproxima de forma coherente a los niveles de rendimiento en calor, DynamoDB puede dividir las particiones ocupadas en función de los patrones de uso observados.

Identifique las teclas de acceso rápido: si la tabla no lo resolvió automáticamente y el rendimiento en caliente es alto o aumentarlo no ayudó, tendrá que identificar las teclas de acceso rápido específicas. Use Identificación de teclas de acceso rápido mediante CloudWatch Contributor Insights para determinar si algún valor de una tecla de partición en particular está caliente. Este es un primer paso para dirigir los esfuerzos de mitigación de manera efectiva. Tenga en cuenta que la identificación no siempre es sencilla, sobre todo en el caso de las particiones calientes móviles (en las que distintas particiones se calientan con el paso del tiempo) o cuando la limitación se desencadena mediante operaciones como los escaneos. Para estos escenarios complejos, es posible que deba analizar los patrones de acceso de la aplicación y correlacionarlos con el momento en que se producen los eventos de limitación.

En función del caso de uso, considere la posibilidad de utilizar lecturas coherentes posteriores: cambie de lecturas altamente coherentes a lecturas coherentes posteriores, que consumen la mitad de RCU y pueden duplicar inmediatamente su capacidad de lectura efectiva. Para las prácticas recomendadas sobre cómo implementar lecturas coherentes posteriores para reducir el consumo de capacidad de lectura, consulte Coherencia de lectura de DynamoDB.

Mejore el diseño de las claves de partición: como solución a largo plazo, tenga en cuenta Mejora del diseño de claves de partición para distribuir el acceso de manera más uniforme entre las particiones. Este enfoque suele proporcionar la solución más completa a los problemas de partición más candentes, ya que aborda la causa raíz. Sin embargo, requiere una planificación cuidadosa, ya que implica importantes desafíos de migración.

Capacidad de precalentamiento: si la limitación persiste, compruebe si la tabla está limitada por su capacidad de Descripción del rendimiento en caliente de DynamoDB. Utilice un rendimiento en caliente o aumente la capacidad de escritura aprovisionada con antelación para los aumentos de tráfico esperados. Al aumentar el rendimiento en caliente, se mejora la capacidad de la tabla para gestionar picos de tráfico repentinos antes de que se produzca una limitación. Con el tiempo, si el rendimiento real se aproxima de forma coherente a los niveles de rendimiento en calor, DynamoDB puede dividir las particiones ocupadas en función de los patrones de uso observados.

Identifique las teclas de acceso rápido: si la tabla no lo resolvió automáticamente y el rendimiento en caliente es alto o aumentarlo no ayudó, tendrá que identificar las teclas de acceso rápido específicas. Use Identificación de teclas de acceso rápido mediante CloudWatch Contributor Insights para determinar si algún valor de una tecla de partición en particular está caliente. Este es un primer paso para dirigir los esfuerzos de mitigación de manera efectiva. Tenga en cuenta estos patrones comunes:

Tenga en cuenta que la limitación de escritura también se puede producir con operaciones como BatchWriteItem o transacciones que afectan a varios elementos simultáneamente. Cuando se limitan los elementos individuales de una solicitud de BatchWriteItem, DynamoDB no propaga estos errores de limitación al código de la aplicación. En su lugar, DynamoDB devuelve información sobre los elementos no procesados de la respuesta, que la aplicación debe gestionar reintentando esos elementos específicos. Para las transacciones, se produce un error en toda la operación con una TransactionCanceledException si algún elemento experimenta limitaciones. Para estos escenarios complejos, es posible que necesite analizar los patrones de escritura y los flujos de trabajo de ingesta de datos de la aplicación, correlacionarlos con el momento en que se producen los eventos de limitación e implementar las estrategias adecuadas de gestión de los reintentos.

Mejore el diseño de las claves de partición: como solución a largo plazo, tenga en cuenta Mejora del diseño de claves de partición para distribuir el acceso de manera más uniforme entre las particiones. Este enfoque suele proporcionar la solución más completa a los problemas de partición más candentes, ya que aborda la causa raíz. Sin embargo, requiere una planificación cuidadosa, ya que implica importantes desafíos de migración.

Capacidad de precalentamiento: si la limitación persiste, compruebe si el GSI está limitado por su capacidad de Descripción del rendimiento en caliente de DynamoDB. Utilice un rendimiento en caliente o aumente la capacidad de lectura aprovisionada con antelación para los aumentos de tráfico esperados. Al aumentar el rendimiento en caliente, se mejora la capacidad del GSI para gestionar picos de tráfico repentinos antes de que se produzca una limitación. Con el tiempo, si el rendimiento real se aproxima de forma coherente a los niveles de rendimiento en calor, DynamoDB puede dividir las particiones ocupadas en función de los patrones de uso observados.

Identifique las teclas de acceso rápido: si el GSI no lo resolvió automáticamente y el rendimiento en caliente es alto o aumentarlo no ayudó, tendrá que identificar las teclas de acceso rápido específicas. Use Identificación de teclas de acceso rápido mediante CloudWatch Contributor Insights para determinar si algún valor de una tecla de partición en particular está caliente. Este es un primer paso para dirigir los esfuerzos de mitigación de manera efectiva. Tenga en cuenta que, en el caso de los GSI, la distribución de claves de partición puede diferir considerablemente de la tabla base, lo que crea diferentes patrones de teclas de acceso rápido.

Rediseñe las claves de partición de GSI: considere si el diseño de la clave de GSI podría estar creando puntos calientes artificiales (como indicadores de estado, claves de solo fecha o atributos booleanos) que concentren las lecturas en un número reducido de particiones. Considere la posibilidad de utilizar claves compuestas que combinen el atributo de baja cardinalidad con un atributo de alta cardinalidad (por ejemplo, “ACTIVE#customer123” en lugar de simplemente “ACTIVE”) o aplique técnicas de Uso de la partición de escritura para distribuir las cargas de trabajo uniformemente en la tabla de DynamoDB a los elementos de la tabla base que afecten a la distribución de GSI para distribuir las escrituras en varias particiones. Aunque la consulta de datos particionados requiere una lógica de aplicación adicional para agregar los resultados, este enfoque evita la limitación al distribuir los patrones de acceso de manera más uniforme.

Rediseñe la clave de partición de GSI: revise el diseño de la clave de partición de GSI para comprobar que tiene la cardinalidad (unicidad) suficiente para distribuir las escrituras de manera uniforme. Una causa común de la limitación de la escritura de GSI es el uso de atributos de baja cardinalidad como claves de partición de GSI (por ejemplo, indicadores de estado con solo unos pocos valores posibles). Aunque la tabla base tenga claves de partición bien distribuidas, el GSI puede seguir teniendo particiones calientes si la clave de partición concentra las escrituras en un número reducido de valores. Por ejemplo, si el 80 % de los elementos tienen “status=ACTIVE”, se crea una partición muy caliente en un GSI basado en el estado. Considere la posibilidad de utilizar claves compuestas que combinen el atributo de baja cardinalidad con un atributo de alta cardinalidad (por ejemplo, “ACTIVE#customer123” en lugar de simplemente “ACTIVE”) o aplique técnicas de Uso de la partición de escritura para distribuir las cargas de trabajo uniformemente en la tabla de DynamoDB a los elementos de la tabla base que afecten a la distribución de GSI para distribuir las escrituras en varias particiones. Aunque la consulta de datos particionados requiere una lógica de aplicación adicional para agregar los resultados, este enfoque evita la limitación al distribuir los patrones de acceso de manera más uniforme.

Capacidad de precalentamiento: compruebe si el GSI está limitado por su capacidad de Descripción del rendimiento en caliente de DynamoDB. Utilice un rendimiento en caliente o aumente la capacidad de lectura aprovisionada con antelación para los aumentos de tráfico esperados. Al aumentar el rendimiento en caliente, se mejora la capacidad del GSI para gestionar picos de tráfico repentinos antes de que se produzca una limitación. Con el tiempo, si el rendimiento real se aproxima de forma coherente a los niveles de rendimiento en calor, DynamoDB puede dividir las particiones ocupadas en función de los patrones de uso observados.

Optimice las proyecciones de GSI: aplique técnicas de Optimización de las proyecciones del GSI para reducir el volumen de escritura en los GSI. Proyectar menos atributos puede reducir considerablemente la capacidad de escritura consumida por cada actualización del GSI.

Eventos de limitación por partición: ReadKeyRangeThroughputThrottleEvents y WriteKeyRangeThroughputThrottleEvents realizan un seguimiento de los casos en los que las particiones individuales superan sus límites de rendimiento. ReadThrottleEvents y WriteThrottleEvents realizan un seguimiento de los casos en que las solicitudes de lectura o escritura superen la capacidad aprovisionada.

Consumo de capacidad: ConsumedReadCapacityUnits y ConsumedWriteCapacityUnits muestran los patrones de uso generales.

Complejidad de la migración de datos: el rediseño de las claves de partición requiere la migración de todos los datos existentes, lo que puede requerir muchos recursos y tiempo en el caso de tablas grandes.

Cambios en el código de la aplicación: todo el código de la aplicación que lee o escribe en la tabla se debe actualizar para utilizar la nueva estructura de claves.

Impacto en la producción: la migración a un nuevo diseño de clave suele requerir tiempo de inactividad o estrategias complejas de escritura doble durante la transición.

Para obtener más información sobre el uso de los GSI para distribuir el tráfico de lectura, consulte Using Global Secondary Indexes to create eventually consistent secondary indexes in Amazon DynamoDB.

Para obtener orientación práctica sobre cómo escalar DynamoDB y administrar particiones calientes, consulte Parte 1: Escalado de DynamoDB: cómo afectan al rendimiento las particiones, las teclas de acceso rápido y la división por calor.

Para obtener información detallada sobre el funcionamiento del mecanismo de división por calor de DynamoDB, sus beneficios y los detalles de la implementación, consulte Part 3: Summary and best practices.

Para obtener estrategias detalladas de partición de escritura, consulte Uso de la partición de escritura para distribuir las cargas de trabajo uniformemente en la tabla de DynamoDB.