Мне интересны эти 2 вторичных индекса и различия между ними. Трудно представить, как это выглядит. И я думаю, это поможет большему количеству людей, чем просто мне.
Разница между локальными и глобальными индексами в DynamoDB
Ответ 1
Локальные вторичные индексы по-прежнему полагаются на оригинальный хэш-ключ. Когда вы поставляете таблицу с диапазоном hash +, подумайте о LSI как хэш + диапазон1, хэш + диапазон2.. хеш + диапазон6. Вы получаете еще 5 атрибутов диапазона для запроса. Кроме того, имеется только одна подготовленная пропускная способность.
Глобальные вторичные индексы определяют новую парадигму - разные хешированные/диапазонные ключи для индекса.
Это нарушает первоначальное использование одного хэш-ключа для каждой таблицы.
Именно поэтому при определении GSI вам необходимо добавить подготовленную пропускную способность на индекс и заплатить за нее.
Более подробную информацию о различиях можно найти в объявлении GSI
Ответ 2
Вот формальное определение из документации:
Глобальный вторичный индекс - индекс с хешем и ключ диапазона, который может отличаться от таковых на столе. Глобальный вторичный индекс считается "глобальным", поскольку запросы по индексу могут охватывать все данных в таблице, во всех разделах.
Локальный вторичный индекс - индекс, который имеет тот же самый хеш-ключ, что и таблицу, но другой ключ диапазона. Местный вторичный индекс является "локальным", в том смысле, что каждое разбиение локального вторичного индекса ограничено к разделу таблицы, который имеет тот же самый хэш-ключ.
Однако различия отличаются от возможностей с точки зрения ключевых определений. Найдите ниже некоторые важные факторы, которые будут напрямую влиять на затраты и усилия для поддержания индексов:
- Пропускная способность:
Локальные вторичные индексы потребляют пропускную способность из таблицы. Когда вы запрашиваете записи через локальный индекс, операция потребляет единицы измерения чтения из таблицы. Когда вы выполняете операцию записи (создаете, обновляете и удаляете) в таблице с локальным индексом, будут две операции записи: одна для таблицы другая для индекса. Обе операции будут потреблять единицы мощности записи из таблицы.
Глобальные вторичные индексы имеют свою собственную подготовленную пропускную способность, когда вы запрашиваете индекс, операция будет потреблять емкость чтения из индекса при выполнении операции записи (создания, обновления, удаления) в таблице с глобальным индексом будут две операции записи, одна для таблицы другая для индекса *.
* При определении заданной пропускной способности для Глобального вторичного индекса убедитесь, что вы уделяете особое внимание следующим требованиям:
Чтобы запись в таблице была успешной, заданная пропускная способность настройки для таблицы и всех ее глобальных вторичных индексов должны иметь достаточную емкость записи для записи; в противном случае запись в таблицу будет дросселирована.
- Управление:
Локальные вторичные индексы могут создаваться только при создании таблицы, нет возможности добавить локальный вторичный индекс в существующую таблицу, также после создания индекса, который вы не можете удалить.
Глобальные вторичные индексы могут создаваться при создании таблицы и добавлении в существующую таблицу, также может быть удалено существующий глобальный вторичный индекс.
- Согласование чтения:
Локальные вторичные индексы поддерживают возможную или сильную согласованность, тогда как глобальный вторичный индекс поддерживает только согласованность.
- Проекция:
Локальные вторичные индексы позволяют извлекать атрибуты, которые не проецируются на индекс (хотя с дополнительными затратами: производительность и единицы потребляемой мощности). С глобальным вторичным индексом вы можете получать атрибуты, проецируемые в индекс.
Особое соображение об уникальности ключей, определенных для вторичных индексов:
В локальном вторичном индексе значение ключа диапазона НЕ должно быть уникальным для заданного значения хэш-ключа, то же самое относится и к глобальным вторичным индексам, значения ключа (хэш и диапазон) НЕ должны быть уникальными.
Источник: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html
Ответ 3
Это возможные поиски по индексу:
- По Hash
- По Hash + Range
- По Hash + Local Index
- По глобальному индексу
- По глобальному индексу + Индекс диапазона
Индексы хэша и диапазона таблицы: Это обычные индексы предыдущих версий 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);
Ответ 4
Другой способ объяснить: LSI помогает вам делать дополнительные запросы к элементам с одним и тем же ключом хэша. GSI помогает выполнять аналогичные запросы по элементам "по всей таблице". Очень полезно.
Если у вас есть таблица профиля пользователя: уникальный идентификатор, имя, адрес электронной почты. Здесь, если вам нужно сделать таблицу запрошенной по имени, электронной почте - тогда единственный способ сделать их GSI (LSI не поможет)
Ответ 5
Один из способов:
LSI - позволяет вам выполнять запрос на одном Hash-Key, используя несколько разных атрибутов для фильтрации или ограничения запроса.
GSI - позволяет выполнять запросы по нескольким Хэш-ключам в таблице, но в результате в качестве дополнительных затрат в этом случае стоит дополнительно.
Более подробная разбивка типов таблиц и способов их работы ниже:
Только хеш
Как вы, наверное, уже знаете; Хэш-ключ сам по себе должен быть уникальным, поскольку запись в уже существующий хэш-ключ перезапишет существующие данные.
Hash + Диапазон
A Hash-Key + Range-Key позволяет вам иметь несколько Hash Keys, которые являются одинаковыми, если у них есть другой ключ диапазона. В этом случае, если вы пишете Hash-Key, который уже существует, но используйте Range-Key, который еще не используется этим Hash-Key, он создает новый элемент, тогда как если элемент с той же комбинацией Hash + Range уже существует, он перезаписывает соответствующий элемент.
Другой способ думать об этом - это как файл с форматом. У вас может быть файл с тем же именем (хэш) как другой, в той же папке (таблице), если их формат (диапазон) отличается. Аналогично, вы можете иметь несколько файлов того же формата, если их имя отличается.
БИС
LSI в основном такой же, как Hash-Key + Range-Key, и следует тем же правилам, что и при создании элементов, за исключением того, что вы также должны предоставлять значения для LSI; они не могут оставаться пустыми /null.
Говорить, что LSI - это "Range-Key 2", не совсем корректно, поскольку вы не можете (используя мой файл и форматировать аналогию ранее), файл с именем: file.format.lsi и file.format.lsi2. Однако вы можете иметь file.format.lsi и file.format2.lsi или file.format.lsi и file2.format.lsi.
В принципе, LSI - это просто "Фильтр-ключ", а не настоящий Range-Key; ваша базовая комбинация значений Hash и Range должна быть уникальной, в то время как значения LSI не обязательно должны быть уникальными. Более простым способом взглянуть на это может быть мысль о LSI как данных в файлах. Вы можете написать код, который находит все файлы с именем "PROJECT101", независимо от их fileFormat, а затем считывает данные внутри, чтобы определить, что должно быть включено в запрос и что опущено. В основном это работает с LSI (просто без дополнительных накладных расходов, чтобы открыть файл для чтения его содержимого).
GSI
Для GSI вы по существу создаете другую таблицу для каждого GSI, но без хлопот поддержки нескольких отдельных таблиц, которые отражают данные между ними; поэтому они стоят дороже.
Итак, для GSI вы можете указать fileName как ваш базовый хэш-ключ и fileFormat в качестве базового ключа диапазона. Затем вы можете указать GSI с хэш-ключом fileName2 и ключ диапазона fileFormat2. Затем вы можете запросить либо fileName, либо fileName2, если хотите, в отличие от LSI, где вы можете запрашивать только fileName.
Основные преимущества заключаются в том, что вам нужно поддерживать только одну таблицу, а не 2, и в любое время, когда вы пишете либо в первичный хэш/диапазон, либо в Hash/Range GSI, другие будут автоматически обновляться так что вы не можете "забыть" обновить другие таблицы, как вы можете, с помощью настройки нескольких таблиц. Кроме того, нет возможности потерять соединение после обновления одного и до обновления другого, например, с настройкой нескольких таблиц.
Кроме того, GSI может "перекрывать" базовую комбинацию Hash/Range. Поэтому, если вы хотите создать таблицу с fileName и fileFormat в качестве базового хэша/диапазона и filePriority и fileName в качестве вашего GSI, вы можете.
Наконец, комбинация GSI Hash + Range не должна быть уникальной, в то время как базовая комбинация Hash + Range должна быть уникальной. Это невозможно с помощью настройки двойной/мульти таблицы, но с GSI. В результате вы ДОЛЖНЫ предоставлять значения как для базового, так и для HSI Hash + Range, при обновлении; ни одно из этих значений не может быть пустым/нулевым.
Ответ 6
Этот документ дает довольно хорошее объяснение:
https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/
Я не мог комментировать этот вопрос, но который лучше с точки зрения производительности записи и чтения:
(Локальный индекс с пропускной способностью чтения и записи в таблице 100) или (глобальный индекс с пропускной способностью чтения/записи 50 вместе с пропускной способностью чтения/записи таблицы 50?)
Мне не нужен отдельный ключ раздела для моего варианта использования, поэтому локальный индекс должен быть достаточным для требуемой функциональности.