Diferencia entre índices locales y globales en DynamoDB

Tengo curiosidad acerca de estos dos índices secundarios y las diferencias entre ellos. Es difícil imaginar cómo se ve esto. Y creo que esto ayudará a más personas que solo a mí.

Los índices secundarios locales todavía se basan en la clave Hash original. Cuando proporciona una tabla con hash + rango, piense en el LSI como hash + rango1, hash + rango2 .. hash + rango6. Obtiene 5 atributos de rango más para consultar. Además, solo hay un rendimiento aprovisionado.

Los índices secundarios globales definen un nuevo paradigma: diferentes claves hash / range por índice.
Esto rompe el uso original de una clave hash por tabla. Esta es también la razón por la cual al definir GSI debe agregar un rendimiento aprovisionado por índice y pagarlo.

Se puede encontrar información más detallada sobre las diferencias en el anuncio de GSI

Aquí está la definición formal de la documentación:

Índice secundario global : un índice con una clave de hash y rango que puede ser diferente de los de la tabla. Un índice secundario global se considera "global" porque las consultas en el índice pueden abarcar todos los datos de una tabla, en todas las particiones.

Índice secundario local : un índice que tiene la misma clave hash que la tabla, pero una clave de rango diferente. Un índice secundario local es "local" en el sentido de que cada partición de un índice secundario local tiene un alcance en una partición de tabla que tiene la misma clave hash.

Sin embargo, las diferencias van mucho más allá de las posibilidades en términos de definiciones clave. Encuentre a continuación algunos factores importantes que afectarán directamente el costo y el esfuerzo para mantener los índices:

• Rendimiento:

Los índices secundarios locales consumen el rendimiento de la tabla. Cuando consulta registros a través del índice local, la operación consume unidades de capacidad de lectura de la tabla. Cuando realiza una operación de escritura (crear, actualizar, eliminar) en una tabla que tiene un índice local, habrá dos operaciones de escritura, una para la tabla y otra para el índice. Ambas operaciones consumirán unidades de capacidad de escritura de la tabla.

Los índices secundarios globales tienen su propio rendimiento aprovisionado, cuando consulta el índice la operación consumirá capacidad de lectura del índice, cuando realiza una operación de escritura (crear, actualizar, eliminar) en una tabla que tiene un índice global, habrá dos operaciones de escritura, una para la tabla y otra para el índice *.

* Al definir el rendimiento aprovisionado para el Índice secundario global, asegúrese de prestar especial atención a los siguientes requisitos:

Para que una escritura de tabla tenga éxito, la configuración de rendimiento aprovisionada para la tabla y todos sus índices secundarios globales deben tener suficiente capacidad de escritura para acomodar la escritura; de lo contrario, la escritura en la tabla se limitará.

• Administración :

Los índices secundarios locales solo pueden crearse cuando está creando la tabla, no hay forma de agregar el índice secundario local a una tabla existente, y una vez que crea el índice, no puede eliminarlo.

Los índices secundarios globales se pueden crear al crear la tabla y agregarlos a una tabla existente, también se permite eliminar un índice secundario global existente.

• Consistencia de lectura:

Los índices secundarios locales admiten la coherencia final o fuerte, mientras que el índice secundario global solo admite la coherencia final.

• Proyección:

Los índices secundarios locales permiten recuperar atributos que no se proyectan en el índice (aunque con un costo adicional: rendimiento y unidades de capacidad consumida). Con el índice secundario global solo puede recuperar los atributos proyectados en el índice.

Consideración especial sobre la unicidad de las claves definidas para los índices secundarios:

En un índice secundario local, el valor de la clave de rango NO necesita ser único para un valor de clave hash dado, lo mismo se aplica a los índices secundarios globales, los valores clave (hash y rango) NO necesitan ser únicos.

Fuente: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

Estas son las posibles búsquedas por índice:

• Por Hash
• Por Hash + Range
• Por Hash + Índice local
• Por índice global
• Por índice global + índice de rango

Índices Hash y Range de una tabla: estos son los índices habituales de versiones anteriores del SDK de Amazon AWS.

Índices globales y locales: son índices 'adicionales' creados en una tabla, además de los índices hash y de rango existentes de la tabla. El índice global es similar a un hash. El índice de rango se comporta de manera similar al índice de rango utilizado con el hash de la tabla. En su modelo de entidad en su código, el captador debe ser anotado de esta manera:

• Para índices globales:

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• Para el índice de rango asociado al índice global:

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

Además, si lee una tabla por un índice global, debe ser una lectura eventual (no coherente):

queryExpression.setConsistentRead(false);

Una forma de decirlo es esta:

LSI: le permite realizar una consulta en una sola clave hash mientras usa múltiples atributos diferentes para "filtrar" o restringir la consulta.

GSI: le permite realizar consultas en múltiples Hash-Keys en una tabla, pero como resultado tiene un costo adicional en el rendimiento.

Un desglose más extenso de los tipos de tabla y cómo funcionan, a continuación:

Hash Only

Como probablemente ya sabes; una Hash-Key en sí misma debe ser única, ya que escribir en una Hash-Key que ya existe sobrescribirá los datos existentes.

Hash + Range

Una Hash-Key + Range-Key le permite tener múltiples Hash Keys que son iguales, siempre que tengan una clave de rango diferente. En este caso, si escribe en una Hash-Key que ya existe, pero usa una Range-Key que aún no usa esa Hash-Key, crea un nuevo elemento, mientras que si un elemento con la misma combinación Hash + Range ya existe, sobrescribe el elemento coincidente.

Otra forma de pensar en esto es como un archivo con un formato. Puede tener un archivo con el mismo nombre (hash) que otro, en la misma carpeta (tabla), siempre que su formato (rango) sea diferente. Del mismo modo, puede tener varios archivos del mismo formato siempre que su nombre sea diferente.

LSI

Un LSI es básicamente lo mismo que una Hash-Key + Range-Key, y sigue las mismas reglas que al crear elementos, excepto que también debe proporcionar valores para los LSI; no pueden dejarse vacíos / nulos.

Decir que un LSI es "Range-Key 2" no es del todo correcto ya que no puede tener (usando mi archivo y la analogía de formato de antes) un archivo llamado: file.format.lsiy file.format.lsi2. Sin embargo, puede tener file.format.lsiy file.format2.lsio file.format.lsiy file2.format.lsi.

Básicamente, un LSI es solo una "clave de filtro", no una clave de rango real; la combinación de valores base de hash y rango aún debe ser única, mientras que los valores de LSI no tienen que ser únicos en absoluto. Una manera más fácil de verlo puede ser pensar en el LSI como datos dentro de los archivos. Puede escribir código que encuentre todos los archivos con el nombre "PROYECTO101", independientemente de su nombre fileFormat, luego lee los datos que contiene para determinar qué se debe incluir en la consulta y qué se omite. Esto es básicamente cómo funciona LSI (solo sin la sobrecarga adicional de abrir el archivo para leer su contenido).

GSI

Para GSI, esencialmente está creando otra tabla para cada GSI, pero sin la molestia de mantener múltiples tablas separadas que reflejen los datos entre ellas; Por eso cuestan más rendimiento.

Entonces, para un GSI, podría especificar fileNamecomo su Hash-Key fileFormatbase y como su Range-Key base. Luego, puede especificar un GSI que tenga una Hash-Key de fileName2y una Range-Key de fileFormat2. Luego puede consultar en cualquiera fileNameo fileName2si lo desea, a diferencia de LSI, donde solo puede consultar fileName.

Las principales ventajas son que solo tiene que mantener una tabla, en lugar de 2, y cada vez que escriba en el Hash / Rango primario o en el / los Hash / Rango (s) de GSI, los otros también se actualizarán automáticamente, así que no puede "olvidarse" de actualizar las otras tablas como puede hacerlo con una configuración de varias tablas. Además, no hay posibilidad de una conexión perdida después de actualizar una y antes de actualizar la otra, como ocurre con la configuración de varias tablas.

Además, un GSI puede "superponerse" a la combinación de Hash / Rango base. Entonces, si desea hacer una tabla con fileNamey fileFormatcomo su Hash / Rango base filePriorityy fileNamecomo su GSI, puede hacerlo .

Por último, una combinación GSI Hash + Range no tiene que ser única, mientras que la combinación base Hash + Range sí tiene que ser única. Esto es algo que no es posible con una configuración de tabla dual / múltiple, pero sí con GSI. Como resultado, DEBE proporcionar valores para la base Y GSI Hash + Range, al actualizar; ninguno de estos valores puede estar vacío / nulo.

Otra forma de explicar: LSI lo ayuda a hacer consultas adicionales sobre elementos con la misma clave de hash. GSI le ayuda a hacer consultas similares en los elementos "en la tabla". Muy útil

Si tiene una tabla de perfil de usuario: id-único, nombre, correo electrónico. Aquí, si necesita hacer que la tabla sea consultable por nombre, correo electrónico, entonces la única forma es hacerlos GSI (LSI no ayudará)

Este documental da una muy buena explicación:

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

No pude comentar sobre esta pregunta, pero cuál es mejor en términos de rendimiento de escritura y lectura:

(Índice local con rendimiento de lectura y escritura de tabla de 100) o (Índice global con rendimiento de lectura / escritura de 50 junto con rendimiento de lectura / escritura de tabla de 50?)

No necesito una clave de partición separada para mi caso de uso, por lo que el índice local debería ser suficiente para la funcionalidad requerida.

Los GSI no se pueden usar para lecturas consistentes.

Las LSI se pueden usar para lecturas consistentes, pero limitarán el tamaño de la partición principal a 10 GB. Además, los LSI solo se pueden crear en la creación de tablas.