3 Características de uma boa Modelagem para bancos NoSQL de Documentos

Implementar novas tecnologias implica na adoção de novos critérios e conhecimentos.

Quando pensamos em bancos de dados, estamos tão habituados a pensar em modelagem relacional que temos dificuldades para pensar como seria modelar para um banco de dados que segue outro paradigma.

No post de hoje, gostaria de compartilhar alguns critérios que podem te ajudar a fazer boa modelagem para bancos de dados NoSQL baseados em documentos.

Uma ótima palestra sobre esse tema

Se você está mesmo interessado no tema, recomendo fortemente que veja essa excelente palestra do Ayende. Trabalhamos juntos (ele lidera o desenvolvimento do RavenDB) e ele explica brilhantemente conceitos que você pode e deve aplicar em sua modelagem.

Por que modelagem em documentos é tão interessante?

Recentemente, resolvi implementar a persistência do IdentityServer4 para RavenDB. Por isso, resolvi dar uma olhada na implementação oficial para EntityFramework. E encontrei isso:

O que temos aqui é um modelo de persistência para os três agregados (!?) que o EntityServer4 mantem.

Bancos de dados relacionais fazem com que objetos complexos sejam persistidos em diversas tabelas. Cada tabela exige uma primary key. A recuperação dos objetos é feita através de JOINs e um bocado de índices são criados apenas para garantir que a recuperação de dados para um documento aconteça em um tempo razoável.

Bancos de dados orientados a documentos, por outro lado, simplificam a persistência. No meu exemplo de persistência acabei não precisando criar um modelo específico para essa finalidade.

Quando modelamos persistência para um banco de dados de documentos:

  • Podemos utilizar uma estrutura de dados complexa (não tabular)
  • Geralmente todas as informações de um agregado são acomodadas em um único documento
  • Há uma identidade com a forma como o negócio pensa os dados.

Para fins de ilustração, considere a forma como um pedido pode ser armazenado no RavenDB:

{
    "Company": "companies/58-A",
    "Employee": "employees/2-A",
    "Freight": 24.95,
    "Lines": [
        {
            "Discount": 0,
            "PricePerUnit": 21,
            "Product": "products/11-A",
            "ProductName": "Queso Cabrales",
            "Quantity": 10
        },
        {
            "Discount": 0,
            "PricePerUnit": 4.5,
            "Product": "products/24-A",
            "ProductName": "Guaraná Fantástica",
            "Quantity": 20
        }
    ],
    "OrderedAt": "1998-05-05T00:00:00.0000000",
    "RequireAt": "1998-06-02T00:00:00.0000000",
    "ShipTo": {
        "City": "México D.F.",
        "Country": "Mexico",
        "Line1": "Calle Dr. Jorge Cash 321",
        "Line2": null,
        "Location": {
            "Latitude": 26.1239528,
            "Longitude": -97.6357883
        },
        "PostalCode": "05033",
        "Region": null
    },
    "ShipVia": "shippers/2-A",
    "ShippedAt": null,
    "@metadata": {
        "@collection": "Orders",
        "@flags": "HasRevisions"
    }
}

Quantas tabelas você precisaria para acomodar todos os dados que você encontra nesse documento?

Sobre o momento da modelagem?

Em um banco de dados relacional, costumamos modelar o esquema (tabelas e relacionamentos) bem no início do projeto. Por que isso é tão ruim? Porque o início do projeto é exatamente o momento que sabemos menos sobre ele (Oren Eini)

Em um banco de dados NoSQL há liberdade de esquema. Isso não significa que você não precise estabelecer algum padrão, mas indica que esse padrão poderá ser modificado com menos sofrimento na medida em que o projeto avança.

Que características um documento bem modelado precisa ter?

Segundo Oren Eini, há três características básicas:

  1. Coerência
  2. Independência
  3. Isolamento

Coerência

Por coerência, Oren se refere a capacidade de um documento deve ser compreensível se lido isoladamente. Ou seja, não sendo necessário carregar outros documentos;

Um documento que faz referências demais a outros documentos implora por “JOINs”.

Um documento que precisa de JOINs para ter significado é apenas um pedaço de informação sem sentido armazenada no banco de dados (Oren Eini)

Independência

Para Oren, um documento é independente quando possui razão própria para existir.

Endereços, por exemplo, não devem ser entendidos como documentos. Por quê? Pois se dois “documentos” representando endereços contiverem as mesmas informações, então, irão se referir, evidentemente, a um mesmo endereço. Percebe?

Agora considere um “pedido”. Mesmo que os valores de dois documentos representando pedidos forem exatamente os mesmos, se houverem identificadores diferentes, então, estes dois documentos podem representar, de fato dois documentos separados.

Se você está vendo forte relacionamento com DDD e conceitos de Agregados, Entidades e Objetos de Valor, está correto. De fato, entidades e agregados são indicativos de documentos. Em outras palavras, se fizer DDD certo, terá uma modelagem de documentos perfeita! A associação de Objetos Valor é feita colocando esses valores “dentro” do documento. A associação com outras Entidades/Agregados é feita através da Identificação.

Isolamento

A modificação nos dados de um documento não deveria implicar na alteração de outros documentos.

Essa ideia, por exemplo, é explicitada na palestra de Oren quando ele diz que os “pedidos” feitos por um cliente não deveriam afetar os dados do cliente em si. Os documentos deveriam fazer referência para o cliente, mas o cliente não deveria ter referência para os pedidos (Referência circular não é uma boa ideia, embora seja expressada frequentemente em frameworks de mapeamento objeto relacional).

Concluindo

Modelagem de documentos para banco de dados NoSQL, para mim, poderia ser explicada como DDD feito de forma correta.

A palestra de Oren apresenta todos esses aspectos em detalhes. Recomendo demais que você a veja.

Comentários?

Créditos para a imagem da capa: unsplash-logoDmitry Ratushny

 

10 Comentários
  1. junior

    Olá Elemar tudo certo? bem mais fácil né kkkkk. uma coisa que sempre me perturba é transação em nosql. estou estudando ddd e vendo algo de nosql.

    1. elemarjr

      No RavenDB, todas as alterações ocorre em uma Unit Of Work (transação)

  2. Marcell Alves

    Vou assistir a palestra. Em todos os projetos que já trabalhei, grande parte do esforço de desenvolvimento consistia em mapear entidades e queries complexas para “objetos” que eram meros sacos de dados.

    Porém, ainda vejo MUITA resistência no mercado corporativo na adoção de bases NoSQL. Entendo que existe uma cultura muito forte de modelar o negócio através de bases de dados relacionais. De fato, modelar o banco normalmente é uma atividade que acontece no início do projeto. Já trabalhei em projeto que os desenvolvedores não eram permitidos de alterar o schema.

    Alguma sugestão para conseguir convencer as empresas a adotarem bancos de dados NoSQL? A mentalidade de muitas empress é que isso é tecnologia pra startup, que é frágil, inseguro, etc.

    1. elemarjr

      Há muita falta de conhecimento. McDonald’s usa nosql.

      Em minhas consultorias venho abordando o tema. 🙂

  3. Renan Ferreira de Aragão

    Bom dia Elemar,

    No post vc fala sobre referenciar o cliente no pedido e não o contrário. O ideal seria somente salvar um id ou um cliente inteiro?

    1. Paulo

      Na verdade acho que deve ser referenciado apenas o ID e não o documento inteiro. Adicionar o documento inteiro causa redundância, e carregamento de dados desnecessários. Imagina o cenário onde você precisa atualizar os dados do cliente, teria que dar um updates em todos os pedidos com o documento do cliente !!! Pra não ter inconsistência em relatório por exemplo. A não ser que você queira guardar histórico do estado do cliente no pedido, mas você pode selecionar alguns campos e não o documento inteiro. É o que eu acho, o que diz Elemar ?

      1. Renan Ferreira de Aragão

        Então, imagino que você esteja correto, mas por causa do trecho que mencionei, fiquei na dúvida sobre o que o Elemar estava querendo falar.

      2. ALSIDNEY

        Cuidado com documentos oficiais como NFe ou NFSe, dados transmitidos nunca podem ser alterados, até mesmo dados do emissor etc, o que estava em vigor no momento da transmissão é o válido e não pode ser alterado, no caso solicita-se cancelamento do documento emitido e uma nova retransmissão, na solução feita para evitarmos problemas foram guardados na tabela da Nota todos os dados e seus itens na tabela detalhe. Espero ter ajudado.

  4. Bruno

    Elemar, beleza, caba?
    As vezes esqueço que você tem blog.
    E, cara, quando lembro e acesso… sempre termino as leituras com um sorriso no rosto por conta da injeção de informações boas.
    Acredito que muitos passem por isso, de não lembrar de seu blog. Isto é ruim pra você e para nós.
    Já pensou em colocar seu blog no medium? Hoje, falando por mim, todos os blogs que acompanho estão lá.
    Uma plataforma perfeita para isso. Não perderia nenhuma postagem sua e você teria uma visibilidade muito maior.

    Este comentário foi só pra dar uma dica (um pedido, na verdade) e dar o feedback de você ta fazendo um ótimo trabalho pra comunidade.
    []’s

  5. Clayton Passos

    Muito bom, Obrigado por compartilhar.
    A algum tempo procuro sobre o tema, e aqui temos a resposta de algumas das minhas dúvidas.
    Gostaria de me aprofundar mais, de ver alguns exemplos de modelagem de dados, comparando o relacional com o de documentos.

    Novamente, muito obrigado!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *