Como modelar dados de jogadores de jogos com o Amazon DynamoDB

A modelagem de dados é o processo de projetar como um aplicativo armazena dados em determinado banco de dados. Com um banco de dados NoSQL como o DynamoDB, a modelagem de dados é diferente da modelagem com um banco de dados relacional. Um banco de dados relacional é criado para oferecer flexibilidade e pode ser uma solução ideal para aplicativos analíticos. Na modelagem de dados relacionais, você começa com suas entidades. Quando você tem um modelo relacional normalizado, pode satisfazer qualquer padrão de consulta necessário em seu aplicativo.

Os bancos de dados NoSQL (não relacionais) são projetados para oferecer velocidade e escalabilidade, não flexibilidade. Embora a performance do seu banco de dados relacional possa decair conforme o aumento da escala, a escalabilidade horizontal de bancos de dados como o DynamoDB oferece performance constante em qualquer escala. Alguns usuários do DynamoDB têm tabelas que são maiores que 100 TB, e a performance de leitura e gravação das tabelas deles é a mesma de quando elas eram menores que 1 GB.

É necessário se desviar do pensamento em relação aos banco de dados relacional típico para alcançar os melhores resultados com um banco de dados NoSQL, como o DynamoDB. Use as melhores práticas a seguir ao modelar dados com o DynamoDB.

1. Aplicar o foco nos padrões de acesso
Ao fazer qualquer tipo de modelagem de dados, você começará com um diagrama entidade-relacionamento que descreve os diferentes objetos (ou entidades) em seu aplicativo e como eles estão conectados (ou os relacionamentos entre as suas entidades).

Nos bancos de dados relacionais, você colocará suas entidades diretamente nas tabelas e especificará os relacionamentos usando chaves estrangeiras. Com suas tabelas de dados definidas, um banco de dados relacional fornece uma linguagem de consulta flexível para retornar dados no formato necessário.

No DynamoDB, você pensa em padrões de acesso antes de modelar sua tabela. O foco dos bancos de dados NoSQL é a velocidade, não a flexibilidade. Primeiro você pergunta como acessará seus dados, em seguida modela seus dados no formato em que serão acessados.

Antes de projetar sua tabela do DynamoDB, documente tudo o que precisa para ler e gravar dados em seu aplicativo. Seja minucioso e pense em todos os fluxos em seu aplicativo, porque você vai otimizar sua tabela para seus padrões de acesso.

2. Otimizar para o número de solicitações ao DynamoDB
Depois de ter documentado as necessidades de padrão de acesso do seu aplicativo, você está pronto para projetar sua tabela. Você deve projetar sua tabela para minimizar o número de solicitações ao DynamoDB para cada padrão de acesso. O ideal é que cada padrão de acesso exija apenas uma única solicitação ao DynamoDB, porque as solicitações de rede são lentas e isso limita o número de solicitações de rede que você fará em seu aplicativo.

Para otimizar em relação ao número de solicitações ao DynamoDB, é necessário entender alguns conceitos principais:

• Chaves primárias
• Índices secundários
• Transações

3. Não simule um modelo relacional
Os iniciantes no DynamoDB geralmente tentam implementar um modelo relacional sobre o DynamoDB não relacional. Se você tentar fazer isso, perderá a maioria dos benefícios do DynamoDB.

Os antipadrões (respostas ineficazes a problemas recorrentes) mais comuns que as pessoas testam com o DynamoDB são:

•  Normalização: em um banco de dados relacional, você normaliza seus dados para reduzir a redundância deles e o espaço de armazenamento, em seguida usa uniões para combinar várias tabelas diferentes. No entanto, as uniões em escala são lentas e caras. O DynamoDB não permite uniões porque elas ficam lentas à medida que sua tabela cresce.
• Um tipo de dados por tabela: sua tabela do DynamoDB geralmente incluirá diferentes tipos de dados em uma única tabela. Em nosso exemplo, temos as entidades User, Game e UserGameMapping em uma única tabela. Em um banco de dados relacional, isso seria modelado como três tabelas diferentes.
• Excesso de índices secundários: as pessoas geralmente tentam criar um índice secundário para cada padrão de acesso adicional de que precisam. O DynamoDB não usa esquemas e isso se aplica aos seus índices também. Use a flexibilidade em seus atributos para reutilizar um único índice secundário em vários tipos de dados da sua tabela. Isso é chamado de sobrecarga de índices.

Nas etapas abaixo, criaremos nosso diagrama entidade-relacionamento e mapearemos nossos padrões de acesso antecipadamente. Essas devem ser sempre as primeiras etapas ao usar o DynamoDB. Em seguida, nos módulos seguintes, implementaremos esses padrões de acesso no design da tabela.