Когда использовать несколько таблиц в DynamoDB?

Лучшие практики DyanmoDB дают понять, что:

Вы должны поддерживать как можно меньше таблиц в приложении DynamoDB. Наиболее хорошо разработанные приложения требуют только одну таблицу.

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

Но что это означает на практике?

Давайте рассмотрим простое приложение с тремя основными объектами: Пользователи, Проекты и Документы. Пользователь владеет несколькими проектами, а Проект может иметь несколько Документов. Обычно нам приходится запрашивать проекты для пользователя и документы для проекта. Количество операций чтения превышает количество записей.

Дизайн таблицы наивного учебника будет использовать три таблицы:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Мы могли бы довольно легко свернуть Projectи Documentв одну Documentsтаблицу:

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

Но зачем останавливаться на достигнутом? Почему не один столик, чтобы управлять ими всеми? Так как Userкорень всего ...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

Тогда у нас будет глобальный индекс, скажем, в emailполе для поиска записей пользователя, а другой - в document-idполе для прямого поиска документов.

Это как это должно работать? Законно ли выбрасывать такие дико расходящиеся виды данных в одну и ту же таблицу? Или второй дизайн с двумя столами - лучший подход?

В какой момент было бы правильно добавить вторую таблицу?

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

1. Какого масштаба вы хотите достичь с помощью этого приложения и модели данных?
2. Что касается шаблонов доступа приложения, каково соотношение операций чтения между этими шаблонами. То есть, какой из них больше других поражен.
3. Из числа шаблонов доступа, которые вы перечислили, сколько раз в секунду они выполняются?

Например, если 80% всех операций чтения предназначены для поиска пользователей в проекте, а это должно произойти со скоростью 30 000 / сек, но в вашем приложении не так много людей пойдут на этот шаг дальше и выяснят документы для проектов, тогда составляет 20% от общего числа операций чтения и может составлять только 2000 операций чтения / сек. Первый из них - это «горячий путь» вашего приложения, и его следует оптимизировать.

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