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.

Tempo de conclusão do módulo: 20 minutos


  • Etapa 1: Crie seu diagrama entidade-relacionamento

    A primeira etapa de qualquer exercício de modelagem de dados é criar um diagrama para mostrar as entidades em seu aplicativo e como elas se relacionam entre si.

    Em nosso aplicativo, temos as seguintes entidades:
    • User
    • Game
    • UserGameMapping

    Uma entidade User representa um usuário em nosso aplicativo. Um usuário pode criar várias entidades Game, e o criador de um jogo determinará qual mapa é jogado e quando o jogo começa. Um User pode criar várias entidades Game, portanto é um relacionamento um-para-muitos entre Users e Games.

    Por fim, um Game contém vários Users e um User pode jogar vários Games diferentes com o tempo. Assim, há um relacionamento muitos-para-muitos entre Users e Games. Podemos representar esse relacionamento com a entidade UserGameMapping.

    Com essas entidades e os relacionamentos em mente, nosso diagrama entidade-relacionamento é mostrado abaixo.

    Module2-step1

    (Clique para aumentar)

    Module2-step1
  • Etapa 2: Considere os padrões de acesso do perfil do usuário

     Os usuários do nosso jogo precisam criar perfis de usuário. Esses perfis incluem dados como nome de usuário, avatar, estatísticas de jogo e outras informações sobre cada usuário. O jogo mostra esses perfis de usuário quando um usuário faz login. Outros usuários podem visualizar o perfil de um usuário para analisar as estatísticas de jogo dele e outros detalhes.

    À medida que um usuário participa dos jogos, as estatísticas de jogo são atualizadas para refletir o número de jogos que o usuário jogo, o número de jogos que o usuário venceu e o número de mortes causadas pelo usuário.

    Com base nessas informações, temos três padrões de acesso:

    •  Criar perfil do usuário (Gravação)
    •  Atualizar perfil do usuário (Gravação)
    • Obter perfil do usuário (Leitura)
  • Etapa 3: Considere os padrões de acesso pré-jogo

    Nosso jogo é do estilo battle royale. Os jogadores podem criar um jogo em um mapa específico e outros podem participar dele. Quando 50 jogadores ingressam no jogo, o jogo começa e nenhum outro jogador pode participar.

    Ao pesquisar por jogos para participar, os jogadores podem querer jogar em determinado mapa. Outros jogadores não se importarão com o mapa e vão procurar jogos abertos em todos os mapas.

    Com base nessas informações, temos estes sete padrões de acesso:

    • Criar jogo (Gravação)
    • Encontrar jogos abertos (Leitura)
    • Encontrar jogos abertos por mapa (Leitura)
    • Visualizar jogo (Leitura)
    • Visualizar usuários no jogo (Leitura)
    • Participar do jogo de um usuário (Gravação)
    • Iniciar jogo(Gravação)
  • Etapa 4: Padrões de acesso no jogo e pós-jogo

    Por fim, vamos considerar os padrões de acesso durante e após o jogo.

    Durante o jogo, os jogadores tentam derrotar outros jogadores com a meta de ser o último jogador vivo. Nosso aplicativo acompanha quantas mortes cada jogador causa durante um jogo e a quantidade de tempo que um jogador sobrevive em um jogo. Se um jogador estiver entre os últimos três sobreviventes em um jogo, ele recebe uma medalha de ouro, prata ou bronze em relação a esse jogo.

    Posteriormente, os jogadores podem querer analisar jogos passados de que participaram ou em que outros jogadores participaram.

    Com base nessas informações, temos três padrões de acesso:

    • Atualizar jogo para o usuário (Gravação)
    • Atualizar jogo (Gravação)
    • Encontrar todos os jogos anteriores de um usuário (Leitura)

    Agora mapeamos todos os padrões de acesso do jogo. Nos módulos seguintes, implementaremos esses padrões de acesso usando o DynamoDB.

    Observe que a fase de planejamento pode precisar de algumas iterações. Comece com uma ideia geral dos padrões de acesso de que seu aplicativo precisa. Mapeie a chave primária, os índices secundários e os atributos em sua tabela. Volte ao início e certifique-se de que todos os padrões acesso sejam atendidos. Quando estiver confiante de que a fase de planejamento está concluída, prossiga para a implementação.