indexing - sort - parallel scan dynamodb

Diferencia entre índices locales y globales en DynamoDB

Question

Tengo curiosidad acerca de estos 2 í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 a mí.

Answer 1

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

Índice secundario global : un índice con un hash y una clave de 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 en 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 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 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 otra para el índice *.

* Al definir el rendimiento previsto 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 aprovisionado para la tabla y todos sus índices secundarios globales debe tener suficiente capacidad de escritura para acomodar la escritura; de lo contrario, se acelerará la escritura en la tabla.

• Administración :

Los índices secundarios locales solo se pueden crear al crear 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 pueden crearse al crear la tabla y agregarse a una tabla existente; también se permite eliminar un índice secundario global existente.

• Leer consistencia:

Los índices secundarios locales admiten una consistencia eventual o sólida, mientras que el índice secundario global solo admite la coherencia final.

• Proyección:

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

Consideración especial sobre la unicidad de las claves definidas a í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 Índices Secundarios Globales, los valores clave (Hash y Rango) NO necesitan ser únicos.

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

Answer 2

Esta documentación da una explicación bastante buena:

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

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

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

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.

Answer 3

Estas son las posibles búsquedas por índice:

• Por Hash
• Por Hash + Rango
• Por índice Hash + Local
• Por índice global
• Por Índice Global + Índice de Rango

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

Índices globales y locales: son índices "adicionales" creados en una tabla, además de los índices de hash y 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 índice Global, debe ser una lectura eventual (no lectura consistente):

queryExpression.setConsistentRead(false);

Answer 4

Los índices secundarios locales aún dependen de la clave hash original. Cuando proporcione una tabla con rango hash +, piense en el LSI como hash + range1, hash + range2 .. hash + range6. Obtiene 5 atributos de rango más para consultar. Además, solo hay un rendimiento previsto.

Global Secondary Indexes define un nuevo paradigma: diferentes claves hash / rango por índice.
Esto rompe el uso original de una clave hash por mesa. Esta es también la razón por la cual al definir GSI se requiere agregar un rendimiento provisto por índice y pagar por él.

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

Answer 5

Otra forma de explicarlo: LSI lo ayuda a realizar consultas adicionales sobre elementos con la misma clave hash. GSI le ayuda a hacer las consultas similares sobre los elementos "al otro lado de la mesa". 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 hacer que sean GSI (LSI no ayuda)

Answer 6

Una forma de decirlo es esto:

LSI: le permite realizar una consulta en una sola tecla 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 tiene un costo adicional en el rendimiento, como resultado.

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

Solo hash

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

Hash + Rango

Una Hash-Key + Range-Key le permite tener múltiples Hash Keys que son iguales, siempre y cuando tengan una tecla de rango diferente. En este caso, si escribe en una Hash-Key que ya existe, pero utiliza una Range-Key que esa Hash-Key ya no utiliza, crea un nuevo elemento, mientras que si es un elemento con la misma combinación de 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 el mismo que un Hash-Key + Range-Key, y sigue las mismas reglas 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 se puede tener (utilizando mi archivo y formato de analogía anterior) un archivo llamado: file.format.lsi y file.format.lsi2 . Sin embargo, puede tener file.format.lsi y file.format2.lsi o file.format.lsi y file2.format.lsi .

Básicamente, un LSI es solo una "clave de filtro", no una verdadera clave de rango; su combinación de valores básicos de Hash y Range 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 un código que encuentre todos los archivos con el nombre "PROJECT101", independientemente de su fileFormat de fileFormat , luego lee los datos internos para determinar qué se debe incluir en la consulta y qué se omite. Básicamente, así es como funciona LSI (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 reflejan datos entre ellas; esta es la razón por la cual cuestan más rendimiento.

Entonces, para un GSI, podría especificar fileName como su Hash-Key base, y fileFormat como su Range-Key base. Luego puede especificar un GSI que tenga una clave Hash de fileName2 y una Range-Key de fileFormat2 . A continuación, puede consultar en fileName o fileName2 si lo desea, a diferencia de LSI, donde solo puede realizar consultas en fileName .

Las principales ventajas son que solo tiene que mantener una tabla, en lugar de 2, y cada vez que escriba en el Hash / Range primario o en el (los) Hash / Range (s) GSI, el otro también se actualizará automáticamente, por lo que no puede "olvidarse" de actualizar la (s) otra (s) tabla (s) como puede con una configuración de varias mesas. Además, no hay posibilidad de perder una conexión después de actualizar una y antes de actualizar la otra, como ocurre con la configuración de varias mesas.

Además, un GSI puede "superponerse" a la combinación básica de Hash / Range. Entonces, si desea hacer una tabla con fileName y fileFormat como su base Hash / Range y filePriority y fileName como su GSI, puede filePriority .

Por último, una combinación GSI Hash + Range no tiene que ser única, mientras que la combinación base Hash + Range tiene que ser única. Esto es algo que no es posible con una configuración de mesa doble / múltiple, pero es 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.