Índices Secundarios en DynamoDB para Consultas Eficientes

En una tabla de Dynamo cada ítem debe contener una clave primaria única. Esta llave debe tener una clave de partición y opcionalmente puede tener una range key (Sort Key). Dentro de la partición, los ítems son ordenados por la range key, en los casos donde la información que necesitemos coincida con nuestra range key el acceso a los elementos va a ser mucho más rápido.

Sin embargo se presentan casos en los cuales la información que necesitamos se encuentra en otro atributo totalmente diferente a la range key, para estos casos podemos utilizar un Local Secondary Index (LSI) el cual tiene la misma clave de partición pero puede tener una range key completamente diferente (por tabla se pueden crear hasta 5 LSI), se debe tener en cuenta que los LSI solamente se pueden crear al momento de crear la tabla, una vez creada no se podrán crear LSI.

Por ejemplo si tenemos la una tabla que mantiene el puntaje de jugadores en diferentes juegos online.

La tabla Scores está conformada de la siguiente forma:

• Llave de partición: GameName → Nombre del Juego

• Llave de ordenamiento (Range o Sort Key): LastGameMatch → Fecha de la última partida disputada en el juego.

Para la tabla SCORE podríamos obtener información de los juegos y la fecha de la última partida disputada en el juego por diferente usuario.

Ahora supongamos que necesitamos responder preguntas diferentes como:

• ¿Cuál es el puntaje máximo en un determinado juego?

• ¿Cuál es la partida ganada más antigua en el juego?

No sería posible obtener la información solicitada con los índices que se tienen actualmente, tendríamos que hacer una operación SCAN que consumiría muchas unidades de lectura.

Para este caso la mejor solución sería utilizar LSI:

• GameName y Score.

• GameName y LastWin.

Con estos LSI podríamos consultar la data con la misma llave de partición (GameName) y obtener resultados sobre otras llaves range como Score y LastWin. Esto nos ayudaría en nuestra tabla a obtener los datos que necesitamos de forma más eficiente y también evitamos el consumo de unidades de lectura de la tabla RCU lo cual se verá reflejado en un ahorro de costos.