在单个应用程序中使用多种数据库类型对数据进行建模

Question

将应用程序的数据模型分解为不同的数据库系统有意义吗？例如，应用程序将所有用户数据和关系存储在图形数据库中（理想用于存储关系），而将其他数据存储在文档数据库中，例如CouchDB或MongoDB？这将要求用户图形数据库引用文档数据库中的唯一标识符，反之亦然。

这是否使数据模型和应用程序复杂化？或者，这是否使用这两种类型的数据库系统的最佳用途来扩展您的应用程序？

Answer 1

它绝对有意义，完全取决于您的应用程序的要求。如果你可以使用其他数据库系统来处理他们擅长的事情。

以全文检索为例。当然，您可以使用像MySql这样的关系数据库进行或多或少复杂的全文搜索。但是有一些系统像例如Lucene/Solr，它们针对这些事情进行了优化，并且可以在数百万个文档中快速搜索。所以你可以使用这些系统来完成他们的特殊任务（这里：做一个漂亮的全文搜索），然后你返回标识符并且可能从RDBMS加载关系结构化数据。

或CouchDB。我在一些项目中使用couchDB作为缓存系统。与关系数据库结合使用。当然，我需要关心一致性，但这绝对值得。它推动了项目中的性能，并将服务器上的负载从2降低到了0.2。 :)

Answer 2

像这样的东西，例如称为跨存储持久性。正如你所提到的，你将存储在关系数据库中的某些数据，graphdb中的社交关系，文档数据库中的用户生成数据（文档）以及用户提供的多媒体文件（图片，音频，视频），如S3 。

它主要关注用例并确保从任何需要的地方访问每个商店的“主”或索引键（来回）。您可以将实际查找封装在您的域或dao图层中。

某些框架（如Spring Data项目）提供了一些初始类型的跨存储持久性，主要是将JPA与不同的NOSQL数据存储集成。例如Spring Data Graph允许它的实体存储在JPA和添加社交图表或其它高度互连的数据作为secondary concern，并充分利用了典型的穿越和其他图形操作的graphdb（如排名，建议等）

Answer 3

的另一个术语为这是多边形持久性。

以下是关于这个问题的两种截然相反的立场：

临： “与此相反，我通晓多种语言的持久性的大风扇这只是意味着使用每个usecases右侧存储后端为。例如文件存储，SQL，图形数据库，数据仓库，内存数据库，网络缓存，NoSQL。现在大多数使用了两个存储，文件和SQL数据库，两者对于每个用例都不是最优的。

• http://codemonkeyism.com/nosql-polyglott-persistence/

精读： “我不认为我需要说我多语种持久的支持者，我相信，在Unix工具哲学。但是，当你的系统增加更多的组件时，你应该意识到这样一个系统的复杂性是“爆炸性的”，所以运营成本也会增长（你记得为什么Twitter开始使用Cassandra？）。且不说更多的组件系统中有更多的关注和关怀，必须投入搞清楚像系统的整体可用性，延迟，吞吐量和一致性的关键环节。”

• http://nosql.mypopescu.com/post/1529816758/why-redis-and-memcached-cassandra-lucene