将应用程序的数据模型分解到不同的数据库系统是否有意义？例如，应用程序将所有用户数据和关系存储在图形数据库中（理想用于存储关系），同时将其他数据存储在文档数据库中，例如CouchDB或MongoDB？这将要求用户图数据库引用文档数据库中的唯一ID，反之亦然。
这是否使数据模型和应用程序变得复杂？或者这是否使用两种类型的数据库系统的最佳用途来扩展您的应用程序？
答案 0 :(得分：4)
它绝对有意义，完全取决于您的应用程序的要求。如果您可以将其他数据库系统用于他们真正擅长的事情。
以全文搜索为例。当然，您可以使用MySql等关系数据库进行或多或少复杂的全文搜索。但有一些系统，例如Lucene / Solr针对此类事物进行了优化，可以快速搜索数百万个文档。所以你可以使用这些系统来完成他们的特殊任务（这里：做一个漂亮的全文搜索），然后你返回标识符，并可能从RDBMS加载关系结构化数据。
或CouchDB。我在一些项目中使用couchDB作为缓存系统。与关系数据库结合使用。当然我需要关心一致性，但它绝对值得努力。它大大推动了项目中的性能，并且例如服务器上的负载从2减少到0.2。 ：）
答案 1 :(得分：3)
这样的东西例如称为跨店持久性。正如您所提到的，您将在关系数据库中存储某些数据，在graphdb中存储社交关系，在文档数据库中存储用户生成的数据（文档），在用于S3的blob存储中提供用户提供的多媒体文件（图片，音频，视频）
主要是关于查看用例并确保从您需要的任何地方，您可以访问每个商店的“主要”或索引键（来回）。您可以将实际查找封装在域或dao层中。
像Spring Data项目这样的一些框架提供了一些开箱即用的初始类型的跨存储持久性，主要是将JPA与不同的NOSQL数据存储区集成在一起。例如Spring Data Graph允许它将您的实体存储在JPA中，并将社交图或其他高度互连的数据添加为secondary concern，并利用graphdb进行典型的遍历和其他图形操作（例如排名，建议等）。 ）
答案 2 :(得分：1)
另一个术语是多语言持久性。
这个问题有两个相反的立场：
临： “与此相反，我是多语言持久性的忠实粉丝。这只是意味着为每个用例使用正确的存储后端。例如文件存储，SQL，图形数据库，数据仓库，内存数据库，网络缓存NoSQL。今天大多使用两个存储，文件和SQL数据库。两者都不是每个用例的最佳选择。“
缺点： “我不认为我需要说我是多语言持久性的支持者。而且我相信Unix工具哲学。但是在为系统添加更多组件时，你应该意识到这样的系统复杂性是”爆炸式的“运营成本也会增长（nb：你还记得为什么Twitter开始使用Cassandra吗？）。更不用说你的系统拥有的组件越多，就必须投入更多的关注和关注，找出整体系统可用性等关键方面，延迟，吞吐量和一致性。“