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

Question

这不是NoSQL vs. SQL类型的问题。我对可以使用RDBMS和NoSQL数据库的组合的场景类型感兴趣，并且 组合的使用非常适合 。一般来说，我理解“它取决于”手头的情况和任务，但我的想法是必须有一些一般/常见的 ¹ 情况，这种组合非常有用。

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

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

应用程序的交叉问题，例如。作为另一个例子，日志记录可能非常适合NoSQL类型的解决方案。

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

如果考虑CAP定理http://en.wikipedia.org/wiki/CAP_theorem，您可以假设关系数据库侧重于一致性和可用性，而NoSQL侧重于可用性和分区容忍度（ EVENTUAL 一致性）。

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

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