¿Cuándo usar varias tablas en DynamoDB?

Las mejores prácticas de DyanmoDB dejan en claro que:

Debe mantener la menor cantidad de tablas posible en una aplicación DynamoDB. La mayoría de las aplicaciones bien diseñadas requieren solo una tabla.

Me resulta divertido que casi todos los tutoriales que he visto sobre DyanmoDB tienen un diseño de varias tablas.

Pero ¿qué significa esto en la práctica?

Consideremos una aplicación simple con tres entidades principales: Usuarios, Proyectos y Documentos. Un usuario posee múltiples proyectos, y un proyecto puede tener múltiples documentos. Por lo general, tenemos que consultar los proyectos para un usuario y los documentos para un proyecto. Las lecturas superan en número a las escrituras por un margen significativo.

El diseño de tabla de un tutorial ingenuo usaría tres tablas:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Podríamos muy fácilmente colapsar Projecty Documenten una Documentstabla:

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

¿Pero por qué parar allí? ¿Por qué no una mesa para gobernarlos a todos? Como el Useres la raíz de todo ...

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

Entonces tendríamos un Índice Global en, digamos, el emailcampo para búsquedas de registros de usuarios, y otro en el document-idcampo para búsquedas directas de documentos.

¿Es así como se supone que debe funcionar? ¿Es legítimo arrojar datos tan divergentes en la misma tabla? ¿O es el segundo diseño de dos tablas un mejor enfoque?

¿En qué punto sería correcto agregar una segunda tabla?

Sí, es legítimo hacer lo que dices. Ambos son en realidad. Hay algunas variables que no tiene aquí y pueden ayudar a guiar cómo se debe hacer el modelo de datos.

1. ¿A qué tipo de escala desea llegar con esta aplicación y modelo de datos?
2. De los patrones de acceso de la aplicación, ¿cuál es la proporción de lecturas entre esos patrones? Lo que significa cuál es el más golpeado sobre los demás.
3. De los patrones de acceso que enumera, ¿cuántas veces por segundo se realizan?

Por ejemplo, si el 80% de todas las lecturas son para encontrar a los usuarios en un proyecto y eso debe suceder 30,000 / seg, pero en su aplicación, no tantas personas irán más allá y encontrarán los documentos para los proyectos, entonces es el 20% de las lecturas totales y solo puede ser de 2000 lecturas / segundo. El primero es el "camino activo" de su aplicación y debe optimizarse para ello.

También piense de esta manera, con una base de datos no relacional como DynamoDB, puede optimizar la forma en que su aplicación usa y accede a los datos y no como la base de datos relacional, donde debe preocuparse mucho por cómo se almacena en la base de datos.