Quando utilizzare più tabelle in DynamoDB?

Le migliori pratiche di DyanmoDB chiariscono che:

È necessario mantenere il minor numero di tabelle possibile in un'applicazione DynamoDB. Le applicazioni più ben progettate richiedono solo una tabella.

Trovo divertente quindi che quasi ogni singolo tutorial che ho visto avere a che fare con DyanmoDB abbia un design multi-tavolo.

Ma cosa significa in pratica?

Consideriamo una semplice applicazione con tre entità principali: Utenti, Progetti e Documenti. Un utente possiede più progetti e un progetto può avere più documenti. In genere dobbiamo eseguire una query sui progetti per un utente e sui documenti per un progetto. Legge un numero maggiore di scritture con un margine significativo.

Il design di una tabella di tutorial ingenuo userebbe tre tabelle:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Potremmo facilmente comprimere Projecte Documentin una Documentstabella:

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

Ma perché fermarsi qui? Perché non un tavolo per domarli tutti? Dal momento che Userè la radice di tutto ...

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

Quindi avremmo un indice globale sul emailcampo per le ricerche dei record degli utenti e un altro sul document-idcampo per le ricerche di documenti diretti.

È così che dovrebbe funzionare? È legittimo inserire tali tipi di dati selvaggiamente divergenti nella stessa tabella? O il secondo design a due tavoli è un approccio migliore?

A che punto sarebbe corretto aggiungere una seconda tabella?

Sì, è lecito fare ciò che stai dicendo. Entrambi lo sono in realtà. Ci sono alcune variabili che non hai qui e possono aiutarti a guidare come il modello di dati dovrebbe essere fatto.

1. Che tipo di scala stai cercando di ottenere con questo modello di applicazione e dati?
2. Dei modelli di accesso dell'applicazione, qual è il rapporto tra letture tra tali modelli. Significa quale è più colpito rispetto agli altri.
3. Dei modelli di accesso che elenchi, quante volte al secondo vengono eseguiti?

Ad esempio, se l'80% di tutte le letture deve trovare gli utenti su un progetto e ciò deve avvenire 30.000 / sec, ma nella tua applicazione non molte persone andranno oltre e scopriranno i documenti per i progetti, quindi è il 20% delle letture complessive e può essere solo di 2000 letture / sec. Quello primo è il "percorso caldo" della tua applicazione e dovrebbe essere ottimizzato per.

Pensaci anche in questo modo, con un database non relazionale come DynamoDB, puoi ottimizzare il modo in cui l'applicazione utilizza e accede ai dati e non come il database relazionale in cui devi preoccuparti molto di come viene archiviato nel database.