Curso Práctico de Bases de Datos en AWS

Curso Práctico de Bases de Datos en AWS

Carlos Andrés Zambrano Barrera

Carlos Andrés Zambrano Barrera

¿Qué es Local Seconday Index?

28/32

Lectura

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.

Screen Shot 2019-08-26 at 3.42.17 PM.png
Screen Shot 2019-08-26 at 3.42.04 PM.png

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.

Screen Shot 2019-08-26 at 3.42.30 PM.png

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.

Screen Shot 2019-08-22 at 3.11.33 PM.png

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.

Aportes 12

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Muy buena explicación.!!

excelente!

asi es utilizando el LSI se optimizaria la consulta y se disminuye los RCU para no ocupar todos los recuros en una consulta tan basica

Creo entender entonces, que, desde que se diseña la base de datos, que es cuando se puede crear el LSI, se sabe qué tipo de consultas se van a estar requiriendo.
O sea, tendremos que realizar scan si tenemos necesidad de otro tipo de búsquedas o filtros

Excelente Información.

excelente 😃

Estupenda explicación, ahora tengo más claro el funcionamiento del local secondary index.

Me imagino que para un experto, el diseño determina una ejecución clara. Sin embargo, la realidad dicta que si me faltara LSI, tendríamos que hacer un backup de la tabla y crearla con los nuevos LSI.

Básicamente las sort key y las LSI nos ayudan a optimizar las querys.

Muy importante el concepto, al momento de hacer filtros con DynamoDB

es interesante, pero siento que cuando el negocio cambie o se necesiten consultar otros datos, tendremos que igualmente consumir rcu porque no se tienen los LSI configurados desde el principio

Muy buena claridad !!!