Разница между локальными и глобальными индексами в DynamoDB

вот формальное определение из документации:

глобальный вторичный индекс - индекс с хэшем и ключом диапазона, который может отличаться от указанного в таблице. Глобальный вторичный индекс считается "глобальным", потому что запросы к индексу могут охватывать все данные в таблице, по всем разделам.

локальный вторичный индекс - индекс, который имеет тот же хэш-ключ как таблица, но другой ключ диапазона. Локальный вторичный индекс - " local" в том смысле, что каждый раздел локального вторичного индекса ограничен к разделу таблицы, который имеет тот же хэш-ключ.

однако различия выходят далеко за рамки возможностей с точки зрения ключевых определений. Ниже приведены некоторые важные факторы, которые непосредственно влияют на стоимость и усилия по поддержанию индексов:

• объем :

локальные вторичные индексы потребляют пропускную способность таблица. При запросе записей через локальный индекс операция потребляет единицы емкости чтения из таблицы. При выполнении операции записи (создание, обновление, удаление) в таблице, имеющей локальный индекс, будет выполняться две операции записи, одна для таблицы, другая для индекса. Обе операции потребляют единицы емкости записи из таблицы.

глобальные вторичные индексы имеют свою выделенную пропускную способность, при запросе индекса операция будет потреблять прочитать емкость из индекса, когда вы выполняете операцию записи (создание, обновление, удаление) в таблице, которая имеет глобальный индекс, будет две операции записи, одна для таблицы, другая для индекса*.

*при определении выделенной пропускной способности для глобального вторичного индекса необходимо обратить особое внимание на следующие требования:

для успешной записи таблицы подготовленная пропускная способность настройки для таблицы и все ее глобальные вторичные индексы должны имейте достаточную емкость записи приспособить запись; в противном случае, запись в таблицу будет регулироваться.

• управление :

локальные вторичные индексы могут быть созданы только при создании таблицы, нет способа Добавить локальный вторичный индекс в существующую таблицу, также после создания индекса вы не можете его удалить.

глобальные вторичные индексы могут быть созданы при создании таблицы и при добавлении в существующую таблицу также допускается удаление существующего глобального вторичного индекса.

• Последовательности Читать:

локальные вторичные индексы поддерживают конечную или сильную согласованность, тогда как глобальный вторичный индекс поддерживает только конечную согласованность.

• проекция:

локальные вторичные индексы позволяют извлекать атрибуты, которые не проецируются на индекс (хотя и с дополнительными затратами: производительность и потребляемые единицы мощности). С помощью глобального вторичного индекса можно получить только атрибуты, проецируемые на индекс.

особое внимание об уникальности ключей, определенных для вторичных индексов:

в локальном вторичном индексе значение ключа диапазона не должно быть уникальным для данного значения хэш-ключа, то же самое относится к глобальным вторичным индексам, значения ключа (хэш и диапазон) не должны быть уникальными.

источник: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

это возможные поиски по индексу:

• По Хэшу
• По Хэшу + Диапазон
• По Хэшу + Локальный Индекс
• по Глобальному индексу
• по Глобальному индексу + индекс диапазона

индексы хэша и диапазона таблицы: Это обычные индексы предыдущих версий Amazon AWS SDK.

глобальные и локальные индексы: Это "дополнительные" индексы, созданные в таблице, в дополнение к существующим индексам хэша и диапазона таблицы. Глобальный индекс похоже на хэш. индекс в диапазоне поведение аналогично индексу диапазона, используемому с хэшем таблицы. В вашей модели сущности в коде геттер должен быть аннотирован следующим образом:

• для глобальных индексов:

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

• для индекса диапазона, связанного с глобальным индекс:

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

кроме того, если Вы читаете таблицу по Глобальному индексу, это должно быть конечное чтение (не согласованное чтение):

queryExpression.setConsistentRead(false);

а это:

LSI-позволяет выполнять запрос по одному хэш-ключу при использовании нескольких различных атрибутов для "фильтрации" или ограничения запроса.

GSI-позволяет выполнять запросы по нескольким хэш-ключам в таблице, но в результате требует дополнительной пропускной способности.

более обширная разбивка типов таблиц и как они работают, ниже:

Хэш Только

как вы, наверное, уже известно; хэш-ключ сам по себе должен быть уникальным, поскольку запись в хэш-ключ, который уже существует, перезапишет существующие данные.

Хэш+Диапазон

хэш-ключ + диапазон-ключ позволяет иметь несколько хэш-ключей, которые являются одинаковыми, если они имеют другой ключ диапазона. В этом случае, если вы пишете в хэш-ключ, который уже существует, но используете Ключ диапазона, который еще не используется этим хэш-ключом, он создает новый элемент, тогда как если элемент с такая же комбинация Hash+Range уже существует, она перезаписывает соответствующий элемент.

другой способ думать об этом, как файл с форматом. Вы можете иметь файл с тем же именем (хэш), что и другой, в той же папке (таблице), если их формат (диапазон) отличается. Кроме того, вы можете иметь несколько файлов одного формата, если их имя отличается.

LSI

LSI в основном совпадает с хэш-ключом + Range-Key, и следует тем же правилам, что и при создании элементов, за исключением того, что вы также должны предоставить значения для LSIs; они не могут быть оставлены пустыми/null.

сказать, что LSI - это "Range-Key 2", не совсем правильно, поскольку вы не можете иметь (используя аналогию с моим файлом и форматом ранее) файл с именем: file.format.lsi и file.format.lsi2. Вы можете, однако, иметь file.format.lsi и file.format2.lsi или file.format.lsi и file2.format.lsi.

в принципе, LSI-это просто "ключ фильтра", а не фактический ключ диапазона; ваша база Комбинация значений хэша и диапазона должна быть уникальной, в то время как значения LSI вообще не должны быть уникальными. Более простой способ взглянуть на это может заключаться в том, чтобы думать о LSI как о данных в файлах. Вы можете написать код, который находит все файлы с именем "PROJECT101", независимо от их fileFormat, затем считывает данные, чтобы определить, что должно быть включено в запрос, и что опущено. Это в основном, как работает LSI (только без дополнительных затрат на открытие файла, чтобы прочитать его оглавление.)

GSI

для GSI вы по существу создаете еще одну таблицу для каждого GSI, но без хлопот по поддержанию нескольких отдельных таблиц, которые отражают данные между ними; вот почему они стоят больше пропускной способности.

так что для GSI, вы можете указать fileName как ваш базовый хэш-ключ, и fileFormat как ваш базовый диапазон-ключ. Затем вы можете указать GSI, который имеет хэш-ключ fileName2 и диапазон-ключ fileFormat2. Затем вы можете запросить на любом fileName или fileName2 если вам нравится, в отличие от LSI, где вы можете только запросить на fileName.

основные преимущества заключаются в том, что вам нужно поддерживать только одну таблицу, а не 2, и в любое время, когда вы пишете либо в основной хэш/диапазон, либо в хэш/диапазон GSI, другой(ы) также будет автоматически обновляться, поэтому вы не можете "забыть" обновить другую таблицу(ы), как вы можете с помощью настройки нескольких таблиц. Кроме того, нет никаких шансов на потерянное соединение после обновления одного и раньше обновление другого, как есть с настройкой нескольких таблиц.

кроме того, GSI может "перекрывать" комбинацию базового хэша/диапазона. Так что если вы хотите сделать таблицу с fileName и fileFormat как ваш базовый хэш / диапазон и filePriority и fileName как ваш GSI, вы можете.

наконец, ГСИ хэш+комбинация диапазон не должен быть уникальным, в то время как хэш-комбинация диапазона не должны быть уникальными. Это то, что невозможно с настройкой двух / нескольких таблиц, но это с GSI. В результате при обновлении необходимо указать значения как для базового, так и для диапазона GSi Hash+; ни одно из этих значений не может быть пустым/null.

другой способ объяснить: LSI помогает вам делать дополнительные запросы к элементам с одним и тем же хэш-ключом. GSI помогает вам выполнять аналогичные запросы по элементам "через таблицу". Так что очень полезно.

Если у вас есть профиль пользователя таблица: уникальный идентификатор, имя, адрес электронной почты. Здесь, Если вам нужно сделать таблицу запрашиваемой по имени, электронной почте - тогда единственный способ сделать их GSI (LSI не поможет)

этот документ дает довольно хорошее объяснение:

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

Я не мог прокомментировать этот вопрос ,но что лучше с точки зрения производительности записи и чтения:

(локальный индекс с пропускной способностью чтения и записи таблицы 100) или (Глобальный индекс с пропускной способностью чтения /записи 50 вместе с пропускной способностью чтения/записи таблицы 50 ? )

Мне не нужен отдельный ключ раздела для моего варианта использования, поэтому локальный индекс должен быть достаточным для требуемой функциональности.