Embora o NoSQL geralmente recomende a desnormalização de modelos de dados, é melhor não ter uma lista ilimitada em uma única entrada de banco de dados. Para modelar esses dados no DynamoDB, você deve usar um lista de adjacências para modelar o relacionamento muitos-para-muitos . Não há relação custo-benefício maneira de modelar os dados, que eu conheço, para permitir que você obtenha todos os dados que deseja em uma única chamada. No entanto, você disse que a velocidade é mais importante (sem fornecer um requisito de latência), então tentarei dar uma ideia de quão rápido você pode obter os dados se armazenados no DynamoDB.
Seus esquemas se tornariam algo assim:
Actor {
ActorId, <-- This is the application/database id, not the actor's actual ID
Name,
Age,
Bio
}
Film {
FilmId, <-- This is the application/database id for the film
Title,
Description,
ReleaseDate
}
ActedIn {
ActorId,
FilmId
}
Para indicar que um ator atuou em um filme, você só precisa realizar uma gravação (que é consistentemente milissegundos de um dígito usando o DynamoDB na minha experiência) para adicionar um item ActedIn à sua tabela.
Para obter todos os filmes de um ator, você precisaria consultar uma vez para obter todos os relacionamentos atuados e, em seguida, ler um lote para obter todos os filmes. As latências típicas para uma consulta (na minha experiência) são inferiores a 10 ms, dependendo das velocidades da rede e da quantidade de dados enviados pela rede. Como o relacionamento ActedIn é um objeto tão pequeno, acho que você poderia esperar um caso médio de 5ms para uma consulta, se sua consulta for originada de algo que também está sendo executado em um datacenter da AWS (EC2, Lambda, etc).
Obter um único item será inferior a 5 ms, e você pode fazer isso em paralelo. Há também uma API BatchGetItems, mas não tenho estatísticas para você sobre isso.
Então, ~ 10ms é rápido o suficiente para você?
Caso contrário, você pode usar DAX , que adiciona uma camada de cache ao DynamoDB e promete latência de solicitação de <1 ms.
Qual é a maneira insustentável e econômica de fazer isso em uma única chamada?
Para cada relacionamento ActedIn, armazene seus dados assim:
ActedIn {
ActorId,
ActorName,
ActorAge,
ActorBio,
FilmId,
FilmTitle,
FilmDescription,
FilmReleaseDate
}
Você só precisa fazer uma consulta para um determinado ator para obter todos os detalhes do filme e apenas uma consulta para obter todos os detalhes do ator para um determinado filme. Na verdade, não faça isso. Os dados duplicados significam que toda vez que você precisar atualizar os detalhes de um ator, será necessário atualizá-lo para cada filme em que ele estava e, da mesma forma, para detalhes do filme. Este será um pesadelo operacional.
Não estou convencido; parece que o NoSQL é terrível para isso.
Você deve se lembrar que o NoSQL vem em muitas variedades (NoSQL =Not Only SQL) e, portanto, mesmo que uma solução NoSQL não funcione para você, você não deve descartá-la completamente. Se você realmente precisar disso em uma única chamada, considere usar um banco de dados de gráficos (que é outro tipo de banco de dados NoSQL).
