As melhores práticas do DyanmoDB deixam claro que:
Você deve manter o menor número possível de tabelas em um aplicativo do DynamoDB. A maioria dos aplicativos bem projetados requerem apenas uma tabela.
Acho divertido, então, que quase todos os tutoriais que vi lidando com o DyanmoDB têm um design de várias tabelas.
Mas o que isso significa na prática?
Vamos considerar um aplicativo simples com três entidades principais: Usuários, Projetos e Documentos. Um usuário possui vários projetos e um projeto pode ter vários documentos. Normalmente, temos que consultar os projetos de um usuário e os documentos de um projeto. As leituras superam as gravações por uma margem significativa.
O design de tabela de um tutorial ingênuo usaria três tabelas:
Users
Hash key
user-id
Projects
Hash key Global Index
project-id user-id
Documents
Hash key Global Index
document-id project-id
Poderíamos facilmente entrar em colapso Projecte Documentem uma Documentstabela:
Documents
Hash key Sort key Global Index
project-id document-id user-id
Mas por que parar por aí? Por que não uma mesa para governar todos eles? Já que o Useré a raiz de tudo...
Users
Hash key Sort key
user-id aspect
--------- ---------
foo user email: [email protected] ...
foo project:1 title: "The Foo Project"
foo project:1:document:2 document-id: 2 ...
Então teríamos um Índice Global, digamos, no emailcampo para pesquisas de registro do usuário e outro no document-idcampo para pesquisas diretas de documentos.
É assim que deve funcionar? É legítimo lançar tipos de dados tão divergentes na mesma tabela? Ou o segundo design de duas tabelas é uma abordagem melhor?
Em que ponto seria correto adicionar uma segunda tabela?
Sim, é legítimo fazer o que você está dizendo. Ambos são na verdade. Existem algumas variáveis que você não tem aqui e podem ajudar a orientar como o modelo de dados deve ser feito.
Por exemplo, se 80% de todas as leituras são para encontrar os usuários em um projeto e isso precisa acontecer 30.000/s, mas em seu aplicativo poucas pessoas vão além e descobrem os documentos para os projetos, então é é 20% do total de leituras e pode ser apenas 2.000 leituras/s. Esse primeiro é o "hot path" do seu aplicativo e deve ser otimizado para.
Pense também desta forma, com um banco de dados não relacional como o DynamoDB, você pode otimizar como seu aplicativo usa e acessa os dados e não como um banco de dados relacional onde você precisa se preocupar muito com como ele é armazenado no banco de dados.