Organização da estrutura do documento em bancos de dados de documentos

O Couchbase não tem esquema. Isso vai contra a história e a experiência dos RDBMS tradicionais, mas provou ser um dos recursos mais elogiados dos bancos de dados NoSQL.

Não ser obrigado a desenvolver um esquema antes de criar o aplicativo economiza muito tempo. Ele permite a criação rápida de protótipos e permite moldar a estrutura do documento à medida que você se aprofunda em seus diferentes usos no aplicativo.

No entanto, a falta de um esquema formal exigido não significa que seus documentos não sejam valorizados por terem uma estrutura consistente ou um esquema "inerente".

Uma das principais considerações ao elaborar seus documentos para o Couchbase é a granularidade da divisão dos dados: um documento ou vários documentos para um único conceito?

Aqui estão os principais tomadores de decisão ao escolher como construir seus dados no Couchbase:

Qual é a aparência desse documento na vida real?
Em nosso caso, temos Breweries e suas cervejas. Temos um substantivo para cada um e, na postagem anterior, tínhamos um documento para cada um. Isso parece natural e faz sentido.

Com que frequência atualizarei isso?

Cervejarias e cervejas são tópicos bastante estáticos. É mais provável que adicionemos documentos sobre cervejas ao portfólio de uma cervejaria do que atualizar a descrição de uma cerveja ou alterar o endereço de uma cervejaria. Essas coisas acontecem, mas são raras quando comparadas com os tickers de ações, dados de sensores ou ações de jogos sociais.

Você deseja que todos esses dados sejam atualizados juntos?
No Couchbase, o documento é o menor nível de atomicidade. Se combinarmos os dados da Brewery e da Beer em um único documento, todas as alterações nos dados da Beer exigirão o envio de todo o documento da Brewery que os contém também. Todas as operações de criação e atualização ocorrem em toda essa coleção como se fosse uma única coisa. Isso tem a vantagem de consolidar atualizações díspares em solicitações únicas e simplificadas, mas tem a desvantagem de exigir uma atualização maior sempre que for feita uma alteração em qualquer um dos conceitos contidos.

Atualmente, parece que temos duas opções disponíveis ao projetar documentos:

• um documento para cada conceito distinto
• um documento para o conceito de "contêiner" maior

No entanto, há uma terceira opção: determinar os dados canônicos posteriormente com o MapReduce. O conteúdo pode ser estruturado de forma a existir mais como um "livro-razão", a partir do qual é possível criar um índice que indique quais são os dados canônicos entre os documentos. Além disso, você pode deixar os dados anteriores (agora "obsoletos") no banco de dados sem ter que se preocupar com os efeitos desses dados obsoletos sobre a forma como você visualiza o material ativo. Isso pode ser vantajoso se você preferir ter esses dados históricos disponíveis. Nesse caso, poderíamos colocar o endereço da cervejaria nos documentos Brewery e Beer e descobrir que uma cerveja foi originalmente produzida no local original da cervejaria. Há muitas opções interessantes!

Como o Couchbase é compatível com a desnormalização, poderíamos colocar os dados da cervejaria em cada documento de cerveja:

Cerveja com objeto da cervejaria

Isso pode nos poupar muito tempo de solicitação. Também poderia servir como um registro histórico de onde a cerveja foi originalmente fabricada (se o endereço da cervejaria mudou anos depois). Se precisarmos das informações canônicas da cervejaria em nosso aplicativo (em vez de dados possivelmente obsoletos), poderemos construir o ID da cervejaria a partir do nome (pelo menos neste aplicativo) e procurar o endereço no documento autorizado da cervejaria. O documento da cervejaria seria a fonte canônica de informações sobre a cervejaria, e as informações sobre o endereço da cervejaria no documento da cerveja poderiam servir como referência histórica.

Prós:

• Obtenha um documento da cerveja e você terá as informações da cervejaria em uma única solicitação
• Informações sobre cervejarias em documentos sobre cervejas poderiam servir a alguns propósitos históricos
• Não há necessidade de usar o MapReduce View Collation para construir relacionamentos

Contras:

• Para obter as informações mais recentes sobre a cervejaria, é necessária uma segunda solicitação ou um multiget (se você souber os dois IDs) ou uma visualização MapReduce

Cervejaria com objetos de cerveja

Vamos inverter esse último exemplo. As cervejarias produzem cervejas. Se eles não forneceram a receita (ou mesmo se forneceram), você não poderá obter aquela cerveja específica, feita daquela maneira específica, com aquela água especial da montanha (ou o que quer que seja) de ninguém além daquela cervejaria. Então, por que não armazenar todas as cervejas em um documento Brewery?

Vamos dar uma olhada em como será essa nova estrutura. As primeiras linhas são do documento original da New Belgium Brewing. A nova adição é a chave "beers" e o objeto de informações sobre cerveja definido como seu valor.

Nosso novo objeto-filho "beers" tem chaves para cada cerveja usando praticamente os mesmos IDs das chaves dos documentos Beer que vimos anteriormente (apenas sem o prefixo "beer_").

Prós:

• Cervejaria e sua cerveja em uma única solicitação (possivelmente bem grande)
• Não há necessidade de usar o View Collation para construir relacionamentos

Contras:

• Os documentos da cerveja não podem ser recuperados diretamente (requer MapReduce)
• O tamanho da resposta pode ser muito grande para grandes cervejarias (+1 para microcervejarias!)

Conclusão

Qualquer uma dessas abordagens pode ser válida para diferentes casos de uso. Nos casos em que você deseja a recuperação rápida de um "pacote" de relacionamento, a rota de um único documento combinado pode ser uma ótima otimização.

Aproveite a liberdade, considere suas opções e construa esse protótipo!

Em seguida, veremos como criar índices a partir dos documentos originais sobre cervejas e cervejarias. Fique ligado!