DynamoDB 1 большой стол или несколько маленьких столов? - PullRequest
Новая
       10

DynamoDB 1 большой стол или несколько маленьких столов?

0 голосов
/ 27 февраля 2019

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

  • Создать учетную запись (1 пользователь владеет 1 учетной записью)
  • Создать профиль (1 учетная запись владеет 1-n профилями))
  • Позволяет профилю загружать 2 типа элементов (1 профилю принадлежит 0-n элементов; элементы различаются по типу и назначению)

Вызов методов API вызывает выполнение AWS Lambdaзапрошенные операции в таблицах DynamoDB.

Мой текущий план выглядит следующим образом:

enter image description here

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

  • Какой хороший способ реализовать эту архитектуру в одной таблице?
  • Существуют ли недостатки при использовании текущейдизайн?
  • Что бы вы указали в качестве первичных / разделов / ключей сортировки / вторичных индексов как в текущем проекте, так и в подходе с одной таблицей?

1 Ответ

0 голосов
/ 28 февраля 2019

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

  • Для данного аккаунта найдите все профили
  • Для данного профилянайти все предметы
  • По заданному профилю и конкретному типу предмета найти все предметы
  • По заданному предмету найти принадлежащий ему профиль
  • По заданному профилю найти личный аккаунт

Одной из прелестей DynamoDB (и, возможно, также является бичом) является то, что он в основном не содержит схем.У вас должны быть обязательные атрибуты первичного ключа для каждого элемента в таблице, но все остальные атрибуты могут быть любыми.Чтобы иметь дизайн DynamoDB только с одной таблицей, вам обычно нужно привыкнуть к идее смешивания типов объектов в одной и той же таблице.

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

Ключ раздела - это поле, которое просто называется pkey (или как вы хотите).Мы также назовем ключ сортировки skey (но опять же, это не имеет значения).Теперь для учетной записи значение pkey равно Account-{{uuid}}, а значение skey будет таким же.Для профиля значение pkey также равно Account-{{uuid}}, но значение skey равно Profile-{{uuid}}.Наконец, для Предмета pkey равно Profile-{{uuid}}, а skey равно Item-{{type}}-{{uuid}}.Для всех атрибутов элемента не беспокойтесь об этом, просто используйте любые атрибуты, которые вы хотите использовать.

Поскольку «родительский» объект всегда является ключом раздела, вы можете получить любой из «дочерние объекты просто запросив идентификатор родительского объекта.Например, выражение вашего ключевого условия для получения всех ItemType2 для профиля будет 

pkey = “Profile-{{uuid}}” AND begins_with(skey, “Item-Type2”)

В этой схеме ваш GSI имеет те же ключи, что и таблица, но в обратном порядке.Вы можете запросить GSI для «Item - {{type}} - {{uuid}}», чтобы получить собственный профиль, и аналогично с профилем - получить собственный счет.

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

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

...