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