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:
- Coerência
- Independência
- 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: Dmitry Ratushny
