поиск по элементам массива в таблице DynamoDB

Question

Мне нужно понять, как можно искать атрибуты DynamoDB, который является частью массива.

Итак, при денормализации таблицы, скажем, человек, у которого много адресов электронной почты. Я бы создал массив в таблицу person для хранения адресов электронной почты.

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

1. Могу ли я создать индекс по адресу электронной почты, который представляет собой отношение «1-много» к записи о человеке и хранится в виде массива, как я понимаю, в DynamoDB.
2. Будет ли этот вторичный индекс глобальным или локальным? Предполагая, у меня есть миллиарды записей о людях?
   3. Если бы я мог создать его как LSI или GSI, объясните плюсы / минусы каждого из них.

Большое спасибо!

Answer 1

Ответ Стю содержит в себе много полезной информации, и он прав: вы не можете использовать Array как таковой в качестве ключа.

Что вы МОЖЕТЕ sometimes сделать, это объединить несколько переменных (или массив) в одну строку с известным разделителем (например, '_'), а затем использовать эту строку в качестве ключа сортировки.

Я использовал эту концепцию для создания составного ключа сортировки, состоящего из нескольких объектов даты ISO 8061 (DyanmoDB сохраняет даты как ISO 8061 в атрибутах типа String). Я также использовал несколько атрибутов, которые не были датами, но были целыми числами с фиксированной длиной символов.

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

Другими словами, объект данных может использовать ключ сортировки следующим образом: электронная почта @ gmail.com_email @ msn.com_email @ someotherplace.com

Тогда вы можете запросить это (если вы знаете, что такое ключ раздела) примерно так:

SELECT * FROM Users WHERE User='Bob' AND Emails LIKE '%email@msn.com%'

ВЫ ДОЛЖНЫ знать ключ разделения, чтобы выполнить запрос независимо от того, какой ключ сортировки вы выбрали, и независимо от того, как создан этот ключ сортировки.

Я думаю, что реальный вопрос, который вы задаете, заключается в том, какими должны быть мои ключи сортировки и ключи раздела? Это будет зависеть от того, какие именно запросы вы хотите сделать и как часто используется каждый тип запроса.

Я обнаружил, что у меня больше успеха с DynamoDB, если я сначала думаю о запросах, которые я хочу сделать, а затем ухожу оттуда.

Слово о вторичных индексах (GSI / LSI)

Проблема в том, что вам все еще нужно «знать» ключ раздела для вашей вторичной структуры данных. GSI / LSI поможет вам избежать необходимости создавать дополнительные таблицы DynamoDB с единственной целью улучшения доступа к данным.

Из Амазонки: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

Для меня это больше похоже на вопрос выбора ключей.

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

GSI (Глобальный вторичный индекс) Глобальный вторичный индекс может помочь в том, что вы можете иметь РАЗЛИЧНЫЙ ключ раздела и ключ сортировки (предположительно, ключ раздела, который вы могли бы «знать» для этого запроса).

Таким образом, вы можете использовать атрибут Email (возможно, составной) в качестве ключа сортировки в GSI, а затем что-то вроде имени службы или стадии регистрации в качестве ключа раздела. Это позволит вам «знать», в каком разделе будет находиться этот пользователь, в зависимости от его прогресса или службы, в которой он зарегистрирован (например).

GSI / LSI по-прежнему необходимо генерировать уникальные значения, используя их ключи, так что имейте это в виду!

Answer 2

Стоит понять терминологию с самого начала. DynamoDB поддерживаемые типы данных :

Скаляр - Строка, число, двоичный код, логическое значение

Документ - Список, Карта

Наборы - Набор строк, Набор номеров, Двоичный набор

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

Emails: ["one@email.com", "two@email.com", "three@email.com"]

Есть несколько важных моментов, касающихся ключевых атрибутов, описанных здесь . Во-первых, ключи должны быть атрибутами верхнего уровня (они не могут быть вложены в документы JSON). Во-вторых, они должны быть скалярных типов (т. Е. String, Number или Binary).

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

С учетом этой схемы вам придется выполнить сканирование , в котором вы установите FilterExpression для вашего атрибута Emails, используя оператор CONTAINS .