3- Se han superado los límites de la cuenta
Las tablas bajo demanda no tienen niveles de capacidad aprovisionados que administrar, pero DynamoDB impone límites de rendimiento por cuenta para evitar una ejecución descontrolada y garantizar un uso justo de los recursos por parte de todos los clientes. Estos límites de cuenta por tabla sirven como medidas de seguridad ajustables y se establecen para cada combinación de cuentas y regiones. Cuando la tasa de consumo de lectura o escritura supera estos límites, DynamoDB devuelve un tipo de motivo de limitación AccountLimitExceeded en la excepción de limitación. Los límites de cuenta predeterminados por tabla se aplican automáticamente cuando las tablas no tienen configurados ajustes de rendimiento máximo personalizados. Si lo desea, puede configurar los ajustes de rendimiento máximo para controlar los costos y mejorar la previsibilidad, o solicitar aumentos de cuota a través de la consola de Cuotas en Amazon DynamoDB si los requisitos de la aplicación superan los límites predeterminados.
El límite de la cuenta superó las medidas de mitigación
Esta sección proporciona una guía para la resolución de situaciones de limitación del límite de las cuentas. Antes de usar esta guía, asegúrese de haber identificado los motivos específicos de limitación a partir del manejo de excepciones de la aplicación y de haber determinado el nombre de recurso de Amazon (ARN) del recurso afectado. Para obtener información sobre cómo recuperar los motivos de la limitación e identificar los recursos limitados, consulte Marco de diagnóstico de limitación de DynamoDB.
Antes de sumergirse en escenarios de limitación específicos, primero determine si realmente es necesario tomar medidas:
-
Evalúe el impacto en el rendimiento: compruebe si la aplicación sigue cumpliendo sus requisitos de rendimiento a pesar de la limitación. Muchas aplicaciones funcionan correctamente dentro o cerca de los límites de la cuenta, especialmente durante las operaciones masivas o las migraciones de datos.
-
Revise los patrones de limitación: si la limitación es intermitente y la aplicación gestiona los reintentos de forma eficaz, los límites actuales pueden ser suficientes para la carga de trabajo.
Si el rendimiento de la aplicación es aceptable, incluso aunque en ocasiones supere los límites de la cuenta, puede elegir simplemente supervisar la situación en lugar de implementar cambios inmediatos.
Si determina que la limitación está provocando problemas de rendimiento inaceptables o problemas de fiabilidad, seleccione un motivo de limitación específico a continuación para ver las opciones de mitigación recomendadas:
TableReadAccountLimitExceeded
Cuando esto ocurre
El consumo de lectura de la tabla ha superado la cuota de rendimiento de lectura por tabla por cuenta para la región. Puede supervisar las métricas de CloudWatch en Diagnóstico y supervisión comunes para analizar el evento de limitación.
Enfoque de resolución
Siga los pasos siguientes para solucionar esta limitación:
-
Solicite aumentos de cuota:
Solicite un aumento del límite de rendimiento de lectura por tabla (código de cuota L-CF0CBE56). Para ver pasos detallados acerca de cómo enviar la solicitud, consulte Solicitud de aumentos de cuota por tabla.
TableWriteAccountLimitExceeded
Cuando esto ocurre
El consumo de escritura de la tabla ha superado la cuota de rendimiento de escritura por tabla por cuenta para la región. Puede supervisar las métricas de CloudWatch en Diagnóstico y supervisión comunes para analizar el evento de limitación.
Enfoque de resolución
Siga los pasos siguientes para solucionar esta limitación:
-
Solicite aumentos de cuota: solicite un aumento del límite de rendimiento de escritura por tabla (código de cuota L-AB614373). Para ver pasos detallados acerca de cómo enviar la solicitud, consulte Solicitud de aumentos de cuota por tabla.
IndexReadAccountLimitExceeded
Cuando esto ocurre
Las operaciones de lectura dirigidas a un índice secundario global (GSI) consumen más rendimiento del que permite la cuota de lectura por tabla de la cuenta en la región de AWS actual. La cuota de rendimiento de lectura por tabla por cuenta se aplica de forma conjunta a una tabla y a todos sus GSI juntos. Puede supervisar las métricas de CloudWatch en Diagnóstico y supervisión comunes para analizar el evento de limitación.
Enfoque de resolución
Elija la resolución adecuada en función de la distribución de la capacidad de la cuenta:
-
Solicite aumentos de cuota: solicite un aumento del límite de rendimiento de lectura por tabla (código de cuota L-CF0CBE56). Para ver pasos detallados acerca de cómo enviar la solicitud, consulte Solicitud de aumentos de cuota por tabla.
-
Optimice el uso del GSI: revise los patrones de diseño y consulta del GSI para reducir el consumo innecesario de capacidad de lectura.
IndexWriteAccountLimitExceeded
Cuando esto ocurre
Las operaciones de escritura en la tabla base generan las actualizaciones correspondientes en un GSI que, en conjunto, superan la cuota de rendimiento de escritura por tabla por cuenta de la región de AWS. Cada escritura en un elemento de la tabla base que contiene atributos indexados por un GSI desencadena una operación de escritura correspondiente a ese GSI. Estas operaciones de escritura combinadas se tienen en cuenta para la cuota de rendimiento de escritura por tabla. Puede supervisar las métricas de CloudWatch en Diagnóstico y supervisión comunes para analizar los patrones y el tiempo de estos eventos de limitación e identificar qué operaciones están causando la excesiva actividad de escritura de GSI.
Enfoque de resolución
Elija la resolución adecuada en función de la distribución de la capacidad de la cuenta:
-
Solicite aumentos de cuota: solicite un aumento del límite de rendimiento de escritura por tabla (código de cuota L-AB614373) para dar cabida a un mayor tráfico de escritura de GSI procedente de las operaciones de la tabla base. La cuota de rendimiento de escritura por tabla se aplica a toda la tabla, incluidos todos los GSI. Para ver pasos detallados acerca de cómo enviar la solicitud, consulte Solicitud de aumentos de cuota por tabla.
-
Optimice las proyecciones del GSI: revise las proyecciones y el diseño del GSI para reducir el volumen de escritura de los GSI.
Diagnóstico y supervisión comunes
Al solucionar problemas por superación del límite de la cuenta, varias métricas de CloudWatch pueden ayudar a identificar si se están alcanzando los límites por tabla o por cuenta y a comprender los patrones de distribución de la capacidad.
Métricas esenciales de CloudWatch
Supervise estas métricas clave para diagnosticar la limitación de los límites de las cuentas:
-
Eventos de limitación de límites de cuentas:
ReadAccountLimitThrottleEventsyWriteAccountLimitThrottleEventsrealizan un seguimiento cuando las solicitudes se limitan debido a los límites por cuenta.ReadThrottleEventsyWriteThrottleEventsrealizan un seguimiento de los casos en que las solicitudes de lectura o escritura superan la capacidad aprovisionada. -
Consumo de capacidad por recurso:
ConsumedReadCapacityUnitsyConsumedWriteCapacityUnitspara cada tabla y GSI muestran el uso individual de los recursos. -
Consumo en toda la cuenta: use expresiones matemáticas de métricas de CloudWatch para sumar la capacidad consumida en todas las tablas y los GSI para supervisar el uso total de la cuenta.
Procedimientos de resolución
Solicitud de aumentos de cuota por tabla
Si las aplicaciones deben funcionar más allá de los límites de rendimiento actuales por tabla, debe enviar una solicitud de aumento de cuota mediante el procedimiento que se indica a continuación. Cada tabla de DynamoDB en la cuenta de AWS (junto con todos sus GSI asociados) está sujeta a estas cuotas de rendimiento dentro de una región específica. Estas cuotas representan la capacidad máxima de lectura o escritura que cualquier tabla individual y sus GSI pueden consumir de forma conjunta, y se aplican de forma independiente a cada tabla y no de forma agregada a todas las tablas de la cuenta.
Si lo desea, también puede establecer límites inferiores por tabla o por GSI configurando sus ajustes de rendimiento máximo bajo demanda.
-
Identifique la cuota específica que necesita aumentar:
-
Límite de rendimiento de lectura por tabla (código de cuota L-CF0CBE56): 40 000 RCU por tabla de forma predeterminada
-
Límite de rendimiento de escritura por tabla (código de cuota L-AB614373): 40 000 WCU por tabla de forma predeterminada
-
-
Use la consola de AWS Service Quotas para solicitar un aumento:
-
Navegación hasta el servicio de DynamoDB en Service Quotas
-
Búsqueda de la cuota adecuada mediante el código de cuota
-
Solicitud de un aumento en función del consumo máximo proyectado
-
-
Proporcione una justificación del aumento, que incluya:
-
Patrones de uso actuales y requisitos de tráfico máximo
-
Justificación empresarial para la capacidad aumentada
-
Plazo para determinar cuándo se necesita aumentar la capacidad
-
nota
Los aumentos de cuotas normalmente tardan entre 24 y 48 horas en procesarse. Planifique las solicitudes en consecuencia y tenga en cuenta estrategias de mitigación temporales mientras espera su aprobación.
Optimización de las proyecciones y el diseño del GSI
Optimice las proyecciones y el diseño del índice secundario global (GSI) para reducir el consumo de capacidad y mejorar el rendimiento.
Estrategias de proyección selectivas
Si las consultas solo necesitan acceder a unos pocos atributos, proyectar solo esos atributos reduce la cantidad de datos que se escriben en el GSI cuando cambian los elementos de la tabla base. Para obtener información sobre los tipos de proyecciones, consulte Proyecciones para índices secundarios globales.
-
Analice los patrones de consulta: revise los patrones de consulta de la aplicación para identificar a qué atributos se accede realmente a través del GSI.
-
Utilice proyecciones selectivas: proyecte solo los atributos que realmente se necesitan en las consultas para reducir el volumen de escritura.
-
Tenga en cuenta
KEYS_ONLY: si las consultas solo necesitan los atributos clave, utilice la proyección deKEYS_ONLYpara minimizar el volumen de escritura. -
Encuentre el equilibrio entre lectura y escritura: proyectar menos atributos reduce el consumo de capacidad de escritura, pero puede requerir lecturas de tablas base adicionales.
Implementación de GSI dispersos
Los GSI dispersos contienen solo elementos que tienen el atributo indexado, en lugar de todos los elementos de la tabla base. Esto reduce la densidad de particiones y mejora el rendimiento cuando se consultan con frecuencia subconjuntos de datos específicos.
-
Diseñe GSI que solo incluyan elementos con valores de atributo específicos.
-
Implemente la indexación condicional configurando solo el atributo de clave de partición de GSI en los elementos que se deben indexar.
-
Utilice claves compuestas en GSI dispersos (por ejemplo, status#timestamp) para distribuir aún más el tráfico dentro del subconjunto de elementos indexados.
Para obtener más información sobre la implementación de estas estrategias, consulte Prácticas recomendadas para utilizar índices secundarios en DynamoDB.