Kiedy używać wielu tabel w DynamoDB?

Najlepsze praktyki DyanmoDB wyjaśniają, że:

W aplikacji DynamoDB należy zachować jak najmniejszą liczbę tabel. Większość dobrze zaprojektowanych aplikacji wymaga tylko jednego stołu.

Uważam to za zabawne, że prawie każdy samouczek, który widziałem podczas pracy z DyanmoDB, ma konstrukcję wielostołową.

Ale co to oznacza w praktyce?

Rozważmy prostą aplikację z trzema głównymi podmiotami: użytkownikami, projektami i dokumentami. Użytkownik jest właścicielem wielu projektów, a Projekt może mieć wiele dokumentów. Zwykle musimy pytać o projekty dla użytkownika oraz o dokumenty dotyczące projektu. Czyta ponad liczbę zapisów ze znacznym marginesem.

Naiwny projekt tabeli wykorzystałby trzy tabele:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Mogliśmy dość łatwo zwinąć Projecti Documentdo jednej Documentstabeli:

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

Ale po co się tu zatrzymywać? Dlaczego nie jeden stół rządzi nimi wszystkimi? Ponieważ Userjest źródłem wszystkiego ...

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     ...

Wtedy mielibyśmy Globalny Indeks na, powiedzmy, emailpolu wyszukiwania rekordów użytkownika, a drugi na document-idpolu bezpośrednich wyszukiwań dokumentów.

Czy tak to powinno działać? Czy uprawnione jest wrzucanie tak bardzo rozbieżnych rodzajów danych do tej samej tabeli? A może druga konstrukcja z dwoma stołami jest lepszym podejściem?

W którym momencie poprawne byłoby dodanie drugiej tabeli?

Tak, uprawnione jest robienie tego, co mówisz. Oba są w rzeczywistości. Istnieje kilka zmiennych, których tu nie ma i które mogą pomóc w wykonaniu modelu danych.

1. Do jakiej skali chcesz dotrzeć dzięki tej aplikacji i modelowi danych?
2. Spośród wzorców dostępu aplikacji jaki jest stosunek odczytów między tymi wzorcami. Oznacza to, który z nich został trafiony najbardziej niż pozostałe.
3. Z wymienionych wzorów dostępu, ile razy są one wykonywane?

Na przykład, jeśli 80% wszystkich odczytów ma znaleźć użytkowników w projekcie, a to musi się wydarzyć 30 000 / s, ale w Twojej aplikacji niewiele osób pójdzie o krok dalej i znajdzie dokumenty dla projektów, to stanowi 20% ogólnych odczytów i może wynosić tylko 2000 odczytów / sek. Ten pierwszy jest „gorącą ścieżką” Twojej aplikacji i powinien zostać zoptymalizowany.

Pomyśl też o tym w ten sposób, dzięki nierelacyjnej bazie danych, takiej jak DynamoDB, możesz zoptymalizować sposób, w jaki aplikacja wykorzystuje i uzyskuje dostęp do danych, a nie jak relacyjna baza danych, w której musisz się bardzo martwić, jak jest ona przechowywana w bazie danych.