Quand utiliser plusieurs tables dans DynamoDB?

Les meilleures pratiques de DyanmoDB indiquent clairement que:

Vous devez conserver le moins de tables possible dans une application DynamoDB. La plupart des applications bien conçues ne nécessitent qu'une seule table.

Je trouve amusant alors que presque tous les tutoriels que j'ai vus concernant DyanmoDB aient une conception multi-tables.

Mais qu'est-ce que cela signifie dans la pratique?

Prenons une application simple avec trois entités principales: les utilisateurs, les projets et les documents. Un utilisateur possède plusieurs projets et un projet peut avoir plusieurs documents. Nous devons généralement interroger les projets d'un utilisateur et les documents d'un projet. Les lectures sont plus nombreuses que les écritures avec une marge importante.

La conception d'un tableau d'un didacticiel naïf utiliserait trois tableaux:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Nous pourrions assez facilement s'effondrer Projectet Documentformer un seul Documentstableau:

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

Mais pourquoi s'arrêter là? Pourquoi pas une table pour les gouverner tous? Puisque le Userest la racine de tout ...

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

Ensuite, nous aurions un index global sur, disons, le emailchamp pour les recherches d'enregistrements utilisateur, et un autre sur le document-idchamp pour les recherches directes de documents.

Est-ce ainsi que cela est censé fonctionner? Est-il légitime de jeter des types de données aussi divergents dans la même table? Ou la deuxième conception à deux tables est-elle une meilleure approche?

À quel moment serait-il correct d'ajouter un deuxième tableau?

Oui, il est légitime de faire ce que vous dites. Les deux le sont en fait. Il y a certaines variables que vous n'avez pas ici et qui peuvent aider à guider la façon dont le modèle de données doit être fait.

1. À quelle échelle souhaitez-vous parvenir avec cette application et ce modèle de données?
2. Parmi les modèles d'accès de l'application, quel est le rapport de lectures entre ces modèles. Ce qui signifie que l'un est le plus touché par rapport aux autres.
3. Parmi les modèles d'accès que vous répertoriez, combien de fois par seconde sont-ils effectués?

Par exemple, si 80% de toutes les lectures visent à trouver les utilisateurs d'un projet et que cela doit se produire 30 000 / s, mais dans votre application, moins de personnes iront plus loin et trouveront les documents des projets, alors il représente 20% des lectures globales et ne peut être que de 2000 lectures / s. Ce premier est le "hot path" de votre application et doit être optimisé pour.

Pensez-y également de cette façon, avec une base de données non relationnelle comme DynamoDB, vous pouvez optimiser la façon dont votre application utilise et accède aux données et pas comme la base de données relationnelle où vous devez vous inquiéter beaucoup de la façon dont elle est stockée dans la base de données.