对于持久化对象,面向文档的数据库是否比关系数据库更合适？

Question

在数据库使用方面,过去十年是ORM的时代,数百人争相在普通的老式RMDBS中坚持我们的对象图.现在,我们似乎正在目睹面向文档的数据库时代的到来.这些 数据库针对无架构文档进行了高度优化,但对于它们并行扩展和查询群集的能力也非常具有吸引力.

面向文档的数据库与RDBMS相比还具有一些优势,可以在面向对象的设计中保持数据模型的持久性.由于表是无模式的,因此可以将属于不同类的对象并排存储在继承层次结构中.此外,随着域模型的更改,只要代码可以处理从旧版本的域类中获取对象,就可以避免在每次更改时都迁移整个数据库.

另一方面,面向文档的数据库的性能优势主要出现在存储更深层文档时.在面向对象的术语中,由其他类组成的类,例如,博客文章及其注释.在大多数这样的例子中,我可以提出,例如博客,读取访问的收益似乎被每次新评论时必须写整个博客文章"文档"的惩罚所抵消.添加.

在我看来,面向文档的数据库可以为面向对象的系统带来显着的好处,如果一个人非常小心地组织深度图中的对象,这些图是针对数据读写方式而优化的,但这意味着了解用例面前.在现实世界中,我们经常不知道,直到我们实际上有一个实时实现,我们可以分析.

那么关系型和面向文档的数据库是一个波动和环形交叉口的情况吗？我对人们的意见和建议感兴趣,特别是如果有人在面向文档的数据库上构建了任何重要的应用程序.

Answer 1

这取决于您的数据结构和数据访问模式.

Document databases store and retrieve documents and basic atomic stored unit is a document. As you said, you need to think about your data-access patterns/use-cases to create a smart document-model. When your domain model can be split and partitioned across some documents, a document-database works like a charm. For example for a blog-software, a CMS or a wiki-software a document-db works extremely well. As long as you can find a good way to squeeze your data into a document you don't have any problems. But don't try to fit a relational-model into a document-database. As soon as you data-access patterns use a lot of 'navigation' on relations, graph or object-databases are a more natural choice.

Another thing is about read/write-performance trade offs. For example a blog-software. In a transitional RDBMS data-model the data is normalized. This means, that reading the data is expensive, because read from different tables, calculate relations with joins etc to read a blog-post. In exchange, changing a tag is inexpensive. In contrast, in a document-database reading a blog-post is cheap, because you just load the post-document. However updating is probably more expensive, because you need to store the whole document. Or worse, go through a lot of documents to change something (rename a tag-scenario). In most systems, reading is way more important than writing. So it actually makes sense to use the renormalized data stores.

I think that on large databases the schema-free design can have its advantages. In RDBMS you need to upgrade you schema which is a really painful process. Especially to convert the existing data to the new schema. In a schema-free database, you application needs to deal with that, which gives more flexibility. For example, you can upgrade the schema on the fly, when a old document is access. This way, you can keep your giant database up and running, while the application handles older versions on the fly.