Коли використовувати декілька таблиць у 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, ви можете оптимізувати, як ваше додаток використовує та отримує доступ до даних, а не як реляційна база даних, де вам доведеться багато переживати про те, як вона зберігається в базі даних.