Indices Secundarios
Amazon DynamoDB proporciona un acceso rápido a los elementos de una tabla especificando sus valores de clave principal. Sin embargo, muchas aplicaciones podrían beneficiarse de disponer de una o varias claves secundarias (o alternativas) para permitir un acceso eficiente a datos con otros atributos aparte de la clave principal. (ref)
DynamoDB admite dos tipos de índices secundarios:
- Global secondary index —Un índice con una clave de partición y una clave de ordenación que pueden diferir de las claves de la tabla base. Un índices secundario global se considera "global" porque las consultas del índice pueden abarcar todos los datos de la tabla base para todas las particiones. Un índices secundario global se almacena en su propio espacio de partición lejos de la tabla base y se escala por separado de la tabla base.
- Índice secundario local—Un índice que tiene la misma clave de partición que la tabla base, pero una clave de ordenación distinta. Un elemento local secondary index es "local" en el sentido de que el ámbito de todas las particiones de un elemento local secondary index corresponde a una partición de tabla base que tiene el mismo valor de clave de partición.
Indice disperso
Cuando crea un GSI ( índice secundario global ), especifica una clave de partición y, de forma opcional, una clave de ordenación.
Solo los elementos de la tabla principal que contienen esos atributos aparecen en el índice secundario global.
Cuando no todos los elementos de la tabla tienen las claves del GSI, se le denomina indice disperso. ref
Por ejemplo:
| pk | sk | studentId | creationDate | enrollment (GSI-1) |
|---|---|---|---|---|
| 202#2023 | CourseA | 23552 | 2020-03-23 | 2020-03-23 |
| 202#2023 | CourseA | 48533 | 2020-03-14 | |
| 202#2025 | CourseB | 98244 | 2020-02-06 | 2020-03-22 |
| 203#2025 | CourseB | 37134 | 2020-05-04 | |
| 203#2025 | CourseA | 72442 | 2020-01-08 | 2020-02-12 |
| 203#2025 | CourseD | 23512 | 2020-05-09 |
El GSI-1 es "disperso" dado que en el sólo tendremos 3 items, los 3 ítem que tienen la propiedad enrollment, que es la partitionKey del GSI-1.
Pasara lo mismo en caso que GSI-1 tenda partitionKey + sortKey.
Agregación
Mantener métricas clave y agregaciones casi en tiempo real se pueden lograr ayudandono con un GSI, como en el ejemplo que proporciona la documentación oficial : Ver ejemplo
Sobrecarga de indice
Diferente tipo de dato, para el mismo atributo. ref
Por ejemplo:
| pk | sk | status | creationDate |
|---|---|---|---|
| 202 | 23123 | open | 2020-03-23 |
| 202 | 96452 | working | 2020-03-14 |
| 202 | usuario1@email.com | working | 2020-02-06 |
| 202 | usuario2@email.com | open | 2020-05-04 |
| 202 | AD-93416 | close | 2020-01-08 |
| 202 | YT-81274 | open | 2020-05-09 |
Asi el mismo atributo (sortKey) en diferentes elementos puede contener tipos de información totalmente diferente.
Fragmentación de escritura en GSI
Cuando tenemos un conjunto de datos y accedemos a ellos por su Clave de partición, pero también necesitamos acceder a uno o varios subconjuntos de estos datos.
Por ejemplo:
| pk | sk | status | creationDate |
|---|---|---|---|
| 202 | 23123 | open | 2020-03-23 |
| 202 | 96452 | working | 2020-03-14 |
| 202 | 45283 | working | 2020-02-06 |
| 203 | 13552 | open | 2020-05-04 |
| 203 | 93416 | close | 2020-01-08 |
| 203 | 81274 | open | 2020-05-09 |
Podemos acceder de forma normal a cada item si conocemos su identificador (pk+sk), pero si necesitamos conocer sólo los items por su status y ordenados por creationDate, podemos crear un GSI fragmentado de la siguiente forma:
- PartitionKey:
statusde tipostring - SortKey:
creationDatede tipostring
Esto nos permitirá obtener todos los items cuya propiedad status tenga un determinado valor.
Se dice "fragmentado" dado que la PK define la partición (nodo) donde se almacena ese item. Al Asignar en este caso al GSI las particiones open,working,close, "fragmentamos" el GSI en 3 nodos diferentes, así, cuando se hace una QUERY a los open, se consulta a ese nodo en particular.
Lectura dispersa ref
Usando el mismo ejemplo anterior, si queremos el listado de los últimos 50 ítems ingresados (creationDate), no podemos usar el indice de la tabla, pero podemos hacer una lectura dispersa al GSI, que incluya todas las particiones.
1 Query al PK=open con limit 50 con el sortKey(creationDate) DESC
1 Query al PK=working con limit 50 con el sortKey(creationDate) DESC
1 Query al PK=close con limit 50 con el sortKey(creationDate) DESC
Al obtener los 3 resultados, obtendremos 150 ítems que nuestra aplicación podría manejar y ordenar para obtener los últimos 50 ítems ingresados.
Quizás no parezca eficiente, pero si la tabla tiene 20.000.000 de ítems, poder hacer una query acotada a 150 ítems sin tener que crear un nuevo GSI, es bastante aceptable.
Clave de ordenación (sortKey) jerárquica ref
Las claves de ordenación compuestas permiten definir en los datos relaciones jerárquicas (de uno a varios) que pueden consultarse en cualquier nivel de la jerarquía.
Por ejemplo, en una tabla con ubicaciones geográficas, la clave de ordenación podría estructurarse del modo siguiente:
[country]#[region]#[state]#[county]#[city]#[neighborhood]
Esto nos permitirá ayudarnos de begins_with para obtener los datos de por ejemplo, todos los estados de una región determinada .
Lista de adyacencia ref
Las listas de adyacencia conforman un patrón de diseño que resulta muy útil para modelar relaciones de varios a varios en Amazon DynamoDB