Блог

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

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

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

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

Пример события:

событие const = { Идентификатор пользователя: идентификатор пользователя, имя события: ‘some_event’, данные: { //любые атрибуты } }

При использовании Dynamodb и разработке его настроек наиболее важно знать ваши шаблоны доступа для того, как вы планируете получать доступ к данным в будущем. Единственное, что требуется для любого документа в динамо — машине, — это его ключ раздела (хэш) (он же ваш пк) — даже его ключ сортировки (диапазона) (он же, sk) необязателен. И все атрибуты являются полностью необязательными и могут на 100% отличаться от любой другой записи, если вы захотите.

Однако, поскольку это НЕ база данных sql, и как только вы получите большие наборы данных, попытка отфильтровать сканирование и попытаться найти данные по информации, которая не является частью вашей комбинации PK/SK, является чрезвычайно дорогостоящей и трудоемкой. Вы хотите спроектировать хранилище данных таким образом, чтобы вы могли получить все, что вам нужно, с помощью одного запроса, и для этого требуется знать его PK и, по крайней мере, часть его SK.

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

Если ваш ‘событие’ как вы планируете организовать свои данные, что делает возможным частью вашей СК — может быть, ваш ПК является вашим идентификатором пользователя и ваша СК не каждое событие названия с даты в формате iso8601 после него (сказать Login#2021-02-28-12:45:55.55T00:00 ) — вы бы тогда быть в состоянии найти все учетные записи данного пользователя с помощью запроса к ПК userId и СК начинается с входа

но допустим, вы хотите просмотреть каждый логин каждого пользователя в промежутке между x и y разами. Вам нужно будет выполнить одну из двух стратегий — создать индекс или дублировать данные, также включив документ, чей PK-логин, а SK-идентификатор пользователя#Дата ISO8601. Есть и плюсы, и минусы.

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

Дублирование данных имеет преимущество в том, что вы всегда в курсе того, что вам нужно 2 записи, и потенциально в вашей таблице может быть даже больше данных, чем вам нужно, но, учитывая то, как работает динамо — машина, на самом деле это не так уж и важно, если ваша настройка PK/SK достаточно надежна.

Итак, в основном ответ таков: определите свои шаблоны доступа и идите оттуда. Читая между строк вашего поста, я бы сказал, что PK идентификатора пользователя и SK имени события#ISO8601-Дата индекс, который переворачивает pk/sk, был бы вашим лучшим выбором. ИЛИ, если вы планируете в основном использовать агрегированные данные, затем измените это на имя события как pk и идентификатор пользователя#ISO8601-Дата в качестве вашего SK с перевернутым индексом, так как это будет более актуальными данными по агрегированной аналитике для всех пользователей, так как другой способ будет более актуальным для каждого пользователя.