哪种类型的情况适合使用关系数据库和NoSQL数据库？

Question

这不是NoSQL vs. SQL类型的问题。 我对可以使用RDBMS和NoSQL数据库的组合的场景类型感兴趣，并且组合的使用非常适合 。 一般情况下，我明白了“这取决于”手头上的形势和任务，但我的想法是，必须有一些普通/通用^1分的情况下这样的组合是非常有用的。

上述每种类型的解决方案都有自己的优点和缺点 - 我所追求的是可以充分利用和利用两者优势的情况/场景。

在我看来，一个可能是电子商务。 RDBMS上的付款，交易等（想想ACID ² ）以及NoSQL数据库中的产品信息和目录。 但是，它适合吗？

应用的横切关注点，例如。 作为另一个例子，日志记录可能非常适合NoSQL类型的解决方案。

或者，为什么不组合使用这两种技术？

编辑：重申一下，我理解SQL和NoSQL都有其固有的优点和缺点，并且某些类型的情况更适合上述数据存储中的一个。

^1我知道Facebook，谷歌等巨头可能会使用这些巨头，但 几乎 在大多数情况下，我认为大多数SO成员都不会使用这些巨大的解决方案。 更典型的日常类型的东西。

² RavenDB是一种支持ACID事务的NoSQL解决方案

Answer 1

NOSQL可能用于从SQL数据存储区复制数据。 在这种情况下，我想从移动SQLITE记录创建文档，并依赖couch或mongo将其复制到服务器上的nosql。 然后，服务器SQL可以处理传入的文档。

Answer 2

一个很好的例子可能是任何分布式数据存储同时在多个节点上更新，并且需要支持可能复杂的即席查询。 节点将“最终一致”，这意味着任何特定节点在任何时间点的数据图像中都可能存在间隙。

这很适合RDBMS，因为间隙可以通过关系之间的“外部”连接非常简单地处理。 关系模型应该比基于图形的模型更适合于此，因为图模型依赖于不同数据元素之间的导航路径。 如果缺少某个元素，则该图形将分为两个图形，因此任何基于路径的查询都可能无效。 关系模型中不存在此问题，因为关系数据库是非导航的 - 数据元素之间没有结构“链接”，因此针对数据的查询的“形状”不需要仅因为数据丢失而更改。

Answer 3

一个明显的答案可能是报告一个例子，在一个简单的应用程序中哪一个比另一个更合适。

例如，您可能希望为OLTP工作使用RavenDB或Couch等文档数据库，因为它为您提供了保存实体的方法，并将这些实体查询为跨文档的平面投影（单查询视图）。 （RavenDB比CouchDB更多，但这既不在这里也不在那里;-)）

您还可以将它用于简单报告，使用Map / Reduce为您提供某些统计信息，以便在某些页面上显示（热门产品，标签云等）。

但是，构建了许多报表系统来查询关系存储，因此您可能希望将数据复制到报表数据库中。

例如，在RavenDB中，您可以选择获取任何索引，并自动将该索引中的数据复制到关系存储中。

这是有道理的，因为以关系格式存储数据意味着您可以执行复杂的跨文档查询并与现有报告产品集成 - 而不会妨碍标准OLTP工作或文档数据库设计。

这只是众多问题中的一个答案，因为还有其他一些例子，其中一种特定类型的数据存储更适合于特定目的，在一天结束时，没有远离它。 （除非你相信VoltDB的人）

Answer 4

除非您在关系数据库根本无法工作的规模下运行，否则NoSQL的一大优势是易于开发 - 例如不需要ORM或数据库升级脚本。 一旦开始在系统的一个部分使用SQL，将其用于其他部分只需要很少的额外工作。

在几乎任何项目中，都会有更适合特定类型数据存储的组件。 重要的问题是差异是否足以证明使用多个数据存储的开销。 通常，这意味着规模，临时报告和数据结构的组合不能很好地映射到关系数据库。

Answer 5

这不是一个真正的编程问题，但这就是我的想法。

如果考虑CAP定理http://en.wikipedia.org/wiki/CAP_theorem ，你可以假设Relationnal数据库集中在一致性和可用性，而NoSQL的专注于可用性和分区耐性（与最终一致性）。

如果您认为SQL查询真的一致，那么您应该考虑使用RDBMS。 如果它不是先决条件，那么您可以使用NoSQL数据库。

这就是为什么大多数时候，最好的答案是同时使用两者，兼顾两者。