Índices secundarios globales e índices secundarios locales

La clave principal de DynamoDB define la única ruta de consulta eficiente de una tabla. Si necesita consultar los elementos mediante un atributo diferente —por ejemplo, si desea encontrar todos los pedidos de un ID de producto cuando la clave de partición de la tabla es CustomerId— tendría que realizar un Scan costoso sin un índice secundario.

Los índices secundarios resuelven este problema manteniendo una copia independiente de los datos, actualizada automáticamente y estructurada en torno a una clave diferente. DynamoDB ofrece dos tipos: Global Secondary Indexes (GSI) y Local Secondary Indexes (LSI), cada uno con distintas ventajas y desventajas.

Un Global Secondary Index permite definir una clave de partición completamente diferente (y, opcionalmente, una clave de ordenación) de la tabla base. El GSI es verdaderamente global: abarca todas las particiones de la tabla base. Puede consultar un GSI para encontrar elementos mediante cualquier atributo que defina como clave de partición del GSI.

Los GSI tienen su propio rendimiento aprovisionado (o heredan el modo bajo demanda), independiente del de la tabla base. Puede crear hasta 20 GSI por tabla y añadirlos o eliminarlos en cualquier momento en una tabla existente.

Un Local Secondary Index comparte la misma clave de partición que la tabla base, pero utiliza una clave de ordenación diferente. Los LSI son «locales» porque solo realizan consultas dentro de una única partición (elementos con la misma clave de partición). Esto hace que los LSI sean ideales para consultar los pedidos de un cliente específico ordenados por distintos atributos.

Los LSI deben definirse en el momento de crear la tabla; no puede añadirlos ni eliminarlos posteriormente. Cada tabla puede tener hasta 5 LSI. Los LSI comparten la capacidad aprovisionada de la tabla base (sin rendimiento independiente) y están sujetos al límite de almacenamiento de 10 GB por clave de partición para la combinación de los datos de la tabla base y del LSI.

A continuación se muestra una comparación lado a lado para facilitar el repaso del examen:

• Clave de partición: la GSI puede diferir de la tabla base; la LSI debe coincidir con la tabla base
• Clave de ordenación: ambas admiten una clave de ordenación distinta de la de la tabla base
• Momento de creación: la GSI puede crearse en cualquier momento; la LSI, solo al crear la tabla
• Rendimiento: la GSI tiene su propio rendimiento; la LSI comparte el rendimiento de la tabla base
• Coherencia: las lecturas de la GSI solo admiten coherencia eventual; las lecturas de la LSI pueden tener coherencia fuerte
• Límites: hasta 20 GSIs; hasta 5 LSIs por tabla

Al crear un índice, se eligen los atributos que se proyectan (copian) en él:

• KEYS_ONLY: solo la clave principal de la tabla base y la clave del índice; es el índice más pequeño, pero requiere llamadas adicionales a GetItem para obtener atributos que no sean claves
• INCLUDE: los atributos de clave más una lista específica de atributos adicionales que se indiquen; ofrece un equilibrio entre el tamaño y el patrón de acceso
• ALL: todos los atributos se proyectan en el índice; es la opción más flexible, pero implica un mayor coste de almacenamiento y escritura

Elija el tipo de proyección según los atributos que realmente necesiten sus consultas. Proyectar atributos innecesarios desperdicia WCUs en cada escritura; proyectar menos atributos de los necesarios obliga a realizar llamadas adicionales a GetItem para obtener los atributos que no están en el índice.

Consultar una GSI utiliza la misma API Query, pero especifica el parámetro --index-name. La consulta se ejecuta sobre el esquema de claves de la GSI, no sobre el de la tabla base. Las consultas a una GSI siempre tienen coherencia eventual: la GSI se actualiza de forma asíncrona después de las escrituras en la tabla base, por lo que existe un breve retraso.

Si un elemento de la tabla base no tiene el atributo de clave de partición de la GSI, no se incluye en ella (patrón de índice disperso). Esta es una técnica eficaz para indexar solo un subconjunto de elementos, como todos los pedidos cuyo estado sea PENDING si la clave de partición de la GSI es Status.

Un índice disperso aprovecha el hecho de que DynamoDB solo proyecta elementos en una GSI si tienen un valor para la clave de partición de la GSI. Al definir la clave de partición de la GSI sobre un atributo que solo tienen algunos elementos, se crea un índice que contiene únicamente ese subconjunto.

Ejemplo: en una tabla Orders, solo los pedidos no enviados tienen un atributo PendingShipmentDate. Una GSI sobre PendingShipmentDate contiene de forma natural únicamente los pedidos no enviados, lo que la convierte en una forma muy eficiente de consultar todos los pedidos pendientes sin examinar toda la tabla.

La sobrecarga de GSI es una técnica avanzada de diseño de tabla única en la que se almacenan distintos tipos de entidades en una misma tabla y se utiliza un atributo de clave de GSI genérico (por ejemplo, GSI1PK y GSI1SK), cuyos valores siguen distintos patrones según el tipo de elemento. De este modo, cada tipo de entidad dispone de su propia ruta de consulta eficiente a través de una única GSI.

Ejemplo: para los elementos User, establezca GSI1PK = 'COUNTRY#US' y GSI1SK = username; para los elementos Order, establezca GSI1PK = 'STATUS#PENDING' y GSI1SK = orderDate. Consultar la GSI con el prefijo adecuado recupera de forma eficiente el tipo de entidad de destino.

La limitación de una GSI se produce de forma independiente de la tabla base. Si las WCUs aprovisionadas de la GSI son demasiado bajas, las escrituras de los elementos que se proyectan en la GSI sufrirán limitación, incluso si la tabla base tiene capacidad de sobra. Supervise ConsumedWriteCapacityUnits y ThrottledRequests por separado para cada GSI.

Un error frecuente es aprovisionar la GSI con una capacidad inferior a la de la tabla base y experimentar después limitaciones cuando un patrón de escritura aumenta repentinamente la tasa de escritura de la GSI. Utilice Auto Scaling en las GSIs o elija el modo On-Demand para evitarlo.

Directrices de decisión para el examen SAA-C03:

• Necesita consultar por un atributo completamente diferente → GSI
• Necesita consultar dentro de la misma partición, pero con un orden diferente, y lo sabe al crear la tabla → LSI
• Necesita lecturas con coherencia fuerte sobre una clave de ordenación alternativa → LSI (es la única opción, ya que las GSIs tienen coherencia eventual)
• Diez o más patrones de consulta distintos → considere el diseño de tabla única con sobrecarga de GSI en lugar de muchas tablas independientes
• Solo necesita recuperar todos los elementos para analizarlos → reconsidere si DynamoDB es la base de datos adecuada

Puede eliminar una GSI en cualquier momento sin afectar a la tabla base. Al añadir una GSI nueva a una tabla existente, DynamoDB rellena el índice de forma asíncrona mediante un examen de la tabla base; en tablas grandes, esto puede tardar desde varios minutos hasta varias horas. Durante el relleno, la tabla base sigue estando completamente disponible para lecturas y escrituras.

Puede supervisar el progreso del relleno en la consola o mediante la API DescribeTable, comprobando el campo IndexStatus del índice: tendrá el valor CREATING durante el relleno y ACTIVE cuando finalice. No consulte la GSI hasta que tenga el estado ACTIVE.

Ponga a prueba su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las GSIs proporcionan claves de partición alternativas y pueden añadirse en cualquier momento, que las LSIs comparten la clave de partición base y deben definirse al crear la tabla y que los tipos de proyección controlan qué atributos se copian en el índice. Las GSIs admiten patrones de índice disperso y de sobrecarga para ofrecer flexibilidad avanzada en las consultas. A continuación, exploraremos DynamoDB Streams y Global Tables.