Una aplicación utiliza una tabla de DynamoDB con los atributos: partNumber (clave de partición), vendor (clave de ordenación), description, productFamily y productType. Algunos módulos consultan frecuentemente listas de productos por productFamily y productType. ¿Qué cambio mejorará el rendimiento de las consultas para esos patrones de acceso?

La creación de un Índice Secundario Global (GSI) con productFamily como clave de partición y productType como clave de ordenación es la mejor solución. Los GSI están diseñados para patrones de consulta que no se ajustan a la clave principal de la tabla, permitiendo consultar atributos no clave de manera eficiente. Al usar productFamily y productType como claves del GSI, las consultas frecuentes por estos atributos se optimizarán significativamente, ya que DynamoDB puede buscar directamente en el índice en lugar de escanear la tabla principal. Un Índice Secundario Local (LSI) no es adecuado porque requiere que la clave de partición sea la misma que la de la tabla principal (partNumber), lo cual no es el caso aquí. Volver a crear la tabla para usar un LSI es innecesario y disruptivo, ya que un GSI puede lograr el objetivo sin cambiar la clave principal de la tabla. Cambiar las consultas para usar operaciones Scan es la peor opción, ya que los Scans son operaciones costosas que leen todos los elementos de la tabla (o índice) y luego filtran, lo que resulta en un rendimiento deficiente y un mayor costo para grandes conjuntos de datos.