Quando estou em eventos, recebo muitas perguntas sobre as diferenças entre o MongoDB e o Couchbase Server, pois ambos estão no espaço NoSQL e são bancos de dados de documentos. Uma pergunta específica está relacionada à modelagem de dados. O MongoDB usa BSON e o Couchbase usa JSON, portanto, o modelo de dados não seria diferente?
Vamos dar uma olhada em alguns modelos de documentos do MongoDB e ver como fazer o mesmo no Couchbase com o mínimo ou nenhum esforço.
Deixe-me começar dizendo que ambos MongoDB e Couchbase têm uma excelente documentação sobre modelagem de documentos NoSQL. Ambos se referem a um conjunto semelhante de práticas que exploraremos.
Modelos de dados incorporados
Como é possível ter documentos NoSQL incrivelmente complexos com objetos e matrizes aninhados, podemos fazer as coisas de forma um pouco diferente do que em um banco de dados relacional.
Veja o seguinte documento do MongoDB, por exemplo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "_id": , "first_name": "Nic", "last_name": "Raboy", "address": { "cidade": "Mountain View", "state": "California" }, "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
No exemplo acima, temos objetos e matrizes aninhados incorporados em um único documento que é definido por um ID de objeto em alguma coleção do MongoDB.
No Couchbase, o mesmo documento do MongoDB pode ter a seguinte aparência:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "_type": "person", "first_name": "Nic", "last_name": "Raboy", "address": { "cidade": "Mountain View", "state": "California" }, "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
Você provavelmente notará que o exemplo do Couchbase acima é quase idêntico ao exemplo do MongoDB, com exceção do _id propriedade tornando-se um _tipo propriedade. No Couchbase, o ID do documento existe como uma meta-propriedade e não dentro do próprio documento. Como não existe o conceito de coleções no Couchbase, os documentos geralmente são diferenciados por uma propriedade de tipo, mas isso não é um requisito.
A incorporação de objetos e matrizes em um único documento é excelente porque limita o número de etapas necessárias para realizar operações comuns nos dados. Entretanto, à medida que o documento se torna maior, o desempenho pode se tornar um problema.
É aqui que a próxima abordagem de modelagem de documentos entra em ação.
Modelos de dados normalizados ou referenciados
Quem vem de um banco de dados relacional sabe que os dados devem ser normalizados em várias tabelas dentro do banco de dados. Essas tabelas são então unidas de alguma forma quando os dados precisam ser acessados em conjunto.
O conceito disso ainda pode ser aplicado no NoSQL, mesmo que não seja exatamente o mesmo que você encontraria em um banco de dados relacional.
Voltando ao primeiro exemplo, vamos fazer o que o MongoDB chama de modelo de dados normalizado:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "_id": , "first_name": "Nic", "last_name": "Raboy", "address" (endereço): , "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
O modelo incorporado mudou ligeiramente ao mover endereço em seu próprio documento. Nesse caso, o endereço agora é igual a um ID de objeto e o novo documento tem a seguinte aparência:
|
1 2 3 4 5 |
{ "_id": , "cidade": "Mountain View", "state": "California" } |
Dividir o documento em vários documentos pode ajudar em várias áreas. Os documentos agora são menores e as operações neles podem ser potencialmente mais rápidas. Os dados também estão normalizados, no sentido de que agora várias pessoas podem existir no mesmo endereço sem precisar se preocupar com a duplicação de dados que existiria no modelo incorporado.
De acordo com a documentação do MongoDB:
... No entanto, os aplicativos do lado do cliente devem emitir consultas de acompanhamento para resolver as referências. Em outras palavras, os modelos de dados normalizados podem exigir mais viagens de ida e volta para o servidor.
A camada do aplicativo é responsável por gerenciar os relacionamentos no modelo normalizado. O aplicativo também precisará fazer mais solicitações ao banco de dados.
Agora, qual seria a aparência do modelo normalizado no Couchbase? Em vez de chamá-lo de normalizado, ele costuma ser chamado de modelo referido no Couchbase, e teria a seguinte aparência:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "_type": "person", "first_name": "Nic", "last_name": "Raboy", "address" (endereço): "address1", "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
Lembre-se de que o id é armazenado como metainformação e que a maioria dos documentos tem uma propriedade para definir que tipo de documento é. Observando a propriedade endereço estamos usando uma chave para um documento diferente. O conceito é o mesmo que o MongoDB tem com ids de objeto, mas no MongoDB, o id de objeto é um tipo de dados.
Observando o documento que contém os dados de endereço, temos algo parecido com isto:
|
1 2 3 4 5 |
{ "_type": "address", "cidade": "Mountain View", "state": "California" } |
A chave do documento ou id do documento acima seria endereço1 para corresponder ao que é esperado no outro documento.
Mas aqui está o ponto alto. Os documentos referidos no Couchbase podem ser unidos em uma única operação no lado do servidor por meio do N1QL, em vez de forçar a camada do aplicativo a cuidar disso.
Conclusão
O que eu provavelmente poderia ter resumido em uma única frase foi que a modelagem de dados no MongoDB e a modelagem de dados no Couchbase são a mesma coisa. Não importa se você usa BSON ou JSON, os conceitos se aplicam a ambos. Se você fosse mudar do MongoDB para o Couchbase, tudo o que você sabia sobre os documentos do MongoDB poderia ser transferido.
As principais diferenças estão relacionadas à forma como você consulta os documentos. É muito mais fácil consultar dados no Couchbase por meio do N1QL e de outras estratégias de consulta, independentemente de como você optou por modelar seus documentos.
Se você estiver interessado em assistir a um vídeo sobre modelagem e consultas que gravei, confira aqui.
Para obter mais informações sobre como usar o Couchbase, consulte o Portal do desenvolvedor do Couchbase que contém exemplos e outras documentações.
