2

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

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

4

3 回答 3

4

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

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

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

于 2011-08-12T20:43:27.070 回答
3

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

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

一些框架，如Spring Data项目，提供了一些开箱即用的初始跨存储持久性，主要将 JPA 与不同的 NOSQL 数据存储集成。例如，Spring Data Graph允许它将您的实体存储在 JPA 中，并添加社交图或其他高度互连的数据作为次要关注点，并利用 graphdb 进行典型的遍历和其他图操作（例如排名、建议等）

于 2011-08-12T21:25:24.967 回答
1

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

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

Pro：“与此相反，我是多语言持久性的忠实拥护者。这仅仅意味着为每个用例使用正确的存储后端。例如文件存储、SQL、图形数据库、数据仓库、内存数据库， “

Con：“我认为我不需要说我是多语言持久性的支持者。而且我相信 Unix 工具哲学。但是在向系统添加更多组件时，你应该意识到这样的系统复杂性是“爆炸式增长”，因此运营成本也会增长（nb：你还记得 Twitter 为何开始使用 Cassandra 吗？）。更不用说你的系统拥有的组件越多，就必须投入更多的注意力和精力来弄清楚整个系统等关键方面可用性、延迟、吞吐量和一致性。”

于 2011-08-16T18:32:06.943 回答