Os bancos de dados orientados a documentos são mais adequados do que os relacionais para objetos persistentes?

Question

Em termos de uso do banco de dados, a última década foi a idade do ORM, com centenas competindo para persistir nossos gráficos de objetos em rmdbs antiquados. Agora, parece que estamos testemunhando a chegada dos bancos de dados orientados a documentos. Esses bancos de dados são altamente otimizados para documentos livres de esquema, mas também são muito atraentes para sua capacidade de escalar e consultar um cluster em paralelo.

Os bancos de dados orientados a documentos também mantêm algumas vantagens sobre os RDBMs para os modelos de dados persistentes em projetos orientados a objetos. Como as tabelas são livres de esquema, pode-se armazenar objetos pertencentes a diferentes classes em uma hierarquia de herança lado a lado. Além disso, à medida que o modelo de domínio muda, desde que o código possa lidar com os objetos de volta de uma versão antiga das classes de domínio, é possível evitar migrar todo o banco de dados a cada alteração.

Por outro lado, os benefícios de desempenho dos bancos de dados orientados a documentos parecem aparecer principalmente ao armazenar documentos mais profundos. Em termos orientados a objetos, as classes compostas por outras classes, por exemplo, uma postagem no blog e seus comentários. Na maioria dos exemplos disso, porém, eu posso inventar, como o blog um, o ganho no acesso de leitura parece ser compensado pela penalidade por ter que escrever a postagem inteira do blog "Documento" toda vez que um novo comentário é adicionado.

Parece-me que os bancos de dados orientados a documentos podem trazer benefícios significativos aos sistemas orientados a objetos, se alguém tomar extremo cuidado para organizar os objetos em gráficos profundos otimizados para a maneira como os dados serão lidos e escritos, mas isso significa conhecer os casos de uso frente. No mundo real, muitas vezes não sabemos até que tenhamos uma implementação ao vivo que podemos perfilar.

Então, é o caso de bancos de dados relacionais e orientados a documentos, um dos balanços e rotatórias? Estou interessado nas opiniões e conselhos das pessoas, em particular se alguém criou algum aplicativo significativo em um banco de dados orientado a documentos.

Answer 1

Bem, depende de como seus dados estão estruturados e dos padrões de acesso de dados.

Os bancos de dados de documentos armazenam e recuperam documentos e a unidade armazenada atômica básica é um documento. Como você disse, você precisa pensar em seus padrões de acesso de dados / casos de uso para criar um modelo de documentos inteligentes. Quando seu modelo de domínio pode ser dividido e particionado em alguns documentos, um documento de dados de documentos funciona como um charme. Por exemplo, para um software de blog, um CMS ou um Wiki-Software que um documento DB funciona extremamente bem. Contanto que você encontre uma boa maneira de espremer seus dados em um documento, você não tem nenhum problema. Mas não tente Para se encaixar em um modelo relacional em um documento de dados. Assim que os padrões de acesso a dados usam muita 'navegação' nas relações, gráficos ou dados de objetos são uma escolha mais natural.

Outra coisa é sobre compensações de leitura/desempenho. Por exemplo, um software de blog. Em um modelo de dados RDBMS de transição, os dados são normalizados. Isso significa que a leitura dos dados é cara, porque leia em diferentes tabelas, calcula as relações com junções etc. para ler um post blog. Em troca, mudar uma etiqueta é barato. Por outro lado, em um documento de dados de documentos, ler um post do blog é barato, porque você apenas carrega o pós-documento. No entanto, a atualização é provavelmente mais cara, porque você precisa armazenar o documento inteiro. Ou pior, passe por muitos documentos para alterar algo (renomeie um cenário de tags). Na maioria dos sistemas, a leitura é muito mais importante do que escrever. Portanto, na verdade faz sentido usar os armazenamentos de dados renormalizados.

Eu acho que em grandes bancos de dados, o design sem esquema pode ter suas vantagens. No RDBMS, você precisa atualizar seu esquema, o que é um processo muito doloroso. Especialmente para converter os dados existentes no novo esquema. Em um banco de dados sem esquema, seu aplicativo precisa lidar com isso, o que oferece mais flexibilidade. Por exemplo, você pode atualizar o esquema em tempo real, quando um documento antigo é o acesso. Dessa forma, você pode manter seu banco de dados gigante em funcionamento, enquanto o aplicativo lida com versões mais antigas em tempo real.