什么类型的情况适合同时使用关系数据库和NoSQL数据库？

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

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

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

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

或者，为什么不将这两种技术结合使用呢

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

我知道Facebook、谷歌等巨头可能会同时使用这两种解决方案，但在几乎所有情况下，我认为大多数会员都不会开发出如此庞大的解决方案。更典型的日常类型的东西

---

2 RavenDB是一个支持ACID事务的NoSQL解决方案

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

如果考虑CAP定理，可以假设关系数据库关注一致性和可用性，而NoSQL则关注可用性和分区容忍度（<>强>最终/强-一致性）。 如果你认为SQL查询真的是一致的，那么你应该考虑使用RDBMS。如果不是先决条件，那么可以使用NoSQL数据库

---

这就是为什么在大多数情况下，最好的答案是同时使用这两种方法，同时利用这两种方法。

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

---

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

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

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

您还可以使用它进行简单的报告，使用Map/Reduce为您提供一些统计信息，以便在某些页面（流行产品、标签云等）上显示

然而，许多报表系统都是为了查询关系存储而构建的，因此您可能希望将数据复制到报表数据库中

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

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

---

这只是众多答案中的一个，因为还有其他一些例子，其中一种特定类型的数据存储更适合于特定的用途，最终无法摆脱这一点。（除非你相信VoltDB的人）

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

---

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

NOSQL可能用于从SQL数据存储复制数据。在这个场景中，我希望从移动SQLITE记录创建文档，并依靠Coach或mongo将其复制到服务器上的nosql。然后，服务器SQL可以处理传入的文档。

我不确定是否也应该在此处添加主观标记。请提供建议。如果我将“NoSQL”方面仅限于面向文档的类型，例如MongoDB、CouchDB、RavenDB，这会对这个问题有所帮助吗？请注意，我在这里对其他答复采取了稍微不同的方法。我试图给出一个适用于关系型NOSQL数据库解决方案的示例，即关系型和NOSQL型数据库。在我看来，NOSQL和relational并不是相互排斥的，尽管有些人似乎认为