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

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

---

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

这肯定是有意义的，并且完全取决于应用程序的要求。如果您可以使用其他数据库系统来处理他们真正擅长的事情

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

---

或者CouchDB。我在一些项目中使用couchDB作为缓存系统。与关系数据库结合使用。当然，我需要关注一致性，但这绝对值得付出努力。它大大提高了项目的性能，并将服务器上的负载从2降低到了0.2.：）

例如，类似这样的东西称为跨存储持久性。正如您提到的，您将在关系数据库中存储某些数据，在graphdb中存储社会关系，在文档db中存储用户生成的数据（文档），在blob存储中存储用户提供的多媒体文件（图片、音频、视频），如S3

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

---

一些框架（如项目）提供了一些初始类型的现成的跨存储持久性，主要是将JPA与不同的NOSQL数据存储集成在一起。例如，允许它将您的实体存储在JPA中，并将社交图或其他高度互联的数据添加为一个数据库，并利用graphdb进行典型的遍历和其他图形操作（例如排名、建议等）。

另一个术语是多语言持久性

在这个问题上有两种相反的立场：

赞成者： “与此相反，我是polyglot persistence的忠实粉丝。这仅仅意味着为您的每个用例使用正确的存储后端。例如文件存储、SQL、图形数据库、数据仓库、内存数据库、网络缓存、NoSQL。现在使用的存储主要有两种，即文件和SQL数据库。这两种存储并不是每种用途的最佳选择案例。”

反对： “我不认为我需要说我是polyglot持久性的支持者。我相信Unix工具的理念。但在向系统中添加更多组件的同时，你应该意识到这样的系统复杂性正在“爆炸”，运营成本也会增加（注：你还记得Twitter为什么开始使用Cassandra吗？）。更不用说，您的系统拥有的组件越多，就必须投入更多的注意力和精力，找出关键方面，如总体系统可用性、延迟、吞吐量和一致性。”

---

谢谢您的回答。我想提到的是，在全文搜索和couchdb这两个示例中，您使用的是多个数据库系统，它们基本上存储相同/重复的数据。您只需使用额外的数据库即可获得更快的查询性能。我的问题主要是询问将数据模型分解为多个系统是否有用，这些系统存储的是不同的数据集，或者更确切地说是数据模型的不同部分。Hmm。是的，视情况而定。例如，在Solr中，我没有复制数据。部分数据在Solr中，其他数据在关系数据库中。我的意思是，在一个当前的项目中，由于爬网数据的存在，文档量非常大，我存储了很多部分，例如Solr和一些结构化数据，它们仍然是关系数据库中模型的一部分。但在这种情况下，Solr数据不会复制任何内容，唯一ID除外，以供参考。：）感谢spring数据图提示。对于那些阅读者来说，这个答案是由Neo4J的人写的，这可能表明它有偏见。有人问过类似的问题。