哪些类型的情况适合同时使用关系数据库和NoSQL数据库？
这不是一个 NoSQL 与 SQL 类型的问题。我对可以使用 RDBMS 和 NoSQL 数据库组合的场景类型感兴趣，并且使用该组合非常适合。一般来说，我理解“这取决于”当前的情况和任务，但我的想法是，一定有一些一般/常见的1情况，这种组合非常有用。
上述每种类型的解决方案都有自己的优点和缺点 - 我追求的是可以充分利用和利用两者的优点的情况/场景。
在我看来，一个可能是 E-商业。 RDBMS 上的支付、交易等（想想 ACID2）以及 NoSQL 数据库中的产品信息和目录。但是，合适吗？
应用程序的横切关注点，例如。作为另一个例子，日志记录可能非常适合 NoSQL 类型解决方案。
或者，为什么不结合使用这两种类型的技术呢？
编辑：重申一下，我知道 SQL 和 NoSQL 都有其固有的优点和缺点，并且某些类型的情况更适合仅上述数据存储之一。
1 我知道 Facebook、Google 等巨头可能会结合使用这些技术，但在几乎所有大多数情况下，我认为大多数 SO 成员都不会从事如此庞大的工作解决方案。更典型的日常类型的东西。
2 RavenDB是一个支持ACID事务的NoSQL解决方案
This is not a NoSQL vs. SQL type question. I am interested in types of scenarios where one can use a combination of a RDBMS and NoSQL database and the use of the combination is well suited. In general, I understand the "it depends" on the situation and task at hand, but my thinking is that there must be some general/common1 situations where this combination is very useful.
Each of the above types of solutions have there own strengths and weaknesses - what I am after is situations/scenarios where the strengths of both can be fully exploited and utilised.
In my mind, one could be E-commerce. Payments, transactions etc on a RDBMS (think ACID2) and product information and catalogues in a NoSQL database. But, is it suitable?
Cross cutting concerns of an application eg. Logging is probably well suited for a NoSQL type solution as another example.
Alternatively, why would you not use both these types of technologies in combination?
Edit: Just to reiterate, I understand that that both SQL and NoSQL have their inherent advantages and disadvantages and that that certain types of situations are more suited to only one of the above data stores.
1 Iknow the giants like Facebook, Google etc probably use a combination of these, but in almost all most cases I don't think most SO members will ever work on such huge solutions. More typical day-to-day type stuff.
2 RavenDB is a NoSQL solution that supports ACID transactions
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一个很好的例子是任何分布式数据存储在多个节点上同时更新并且需要支持潜在复杂的即席查询。节点将“最终一致”，这意味着任何特定节点的数据图像在任何时间点都可能存在间隙。
这非常适合 RDBMS，因为可以通过关系之间的“外”连接非常简单地处理间隙。关系模型应该比基于图的模型更适合这种情况，因为图模型依赖于不同数据元素之间的导航路径。如果缺少某个元素，则该图将分为两个图，因此任何基于路径的查询都可能无效。这个问题在关系模型中不存在，因为关系数据库是非导航的——数据元素之间没有结构“链接”，因此针对数据的查询的“形状”不需要仅仅因为数据丢失而改变。
A good example could be any distributed data store being updated at multiple nodes simultaneously and needing to support potentially complex ad hoc queries. Nodes would be "eventually consistent", which means any particular node might have gaps in its picture of the data at any point in time.
This suits an RDBMS well because the gaps can be handled very simply by "outer" joins between relations. The relational model should be a better fit for this than, say, a graph-based model because the graph model relies on navigational paths between different data elements. If an element is missing then the graph is broken into two graphs and so any path-based query might be invalidated. This problem doesn't exist in the relational model because relational databases are non-navigational - there are no structural "links" between data elements so the "shape" of queries against the data does not need to change just because data is missing.
一个明显的答案可能是作为一个示例来报告在简单应用程序中一个比另一个更合适的情况。
例如，您可能希望在 OLTP 工作中使用 RavenDB 或 Couch 等文档数据库，因为它为您提供了保存实体并将这些实体查询到跨文档的扁平投影（单查询视图）的方法。 （RavenDB 比 CouchDB 多，但这既不在这里也不在那里；-））
您还可以使用它进行简单的报告，使用 Map/Reduce 为您提供一些统计数据以显示在某些页面（热门产品、标签云等）上。
但是，许多报告系统都是为了查询关系存储而构建的，因此您可能希望将数据复制到报告数据库中。
例如，在 RavenDB 中，您可以选择采用任何索引，并自动将该索引中的数据复制到关系存储中。
这是有道理的，因为拥有关系格式的数据意味着您可以执行复杂的跨文档查询并与现有报告产品集成，而不会妨碍标准 OLTP 工作或文档数据库设计。
这只是众多答案中的一个，因为还有其他示例，其中一种特定类型的数据存储更适合特定目的，最终无法摆脱这一点。 （除非你相信 VoltDB 的人）
An obvious answer could be reporting as an example as to where one is more appropriate than the other in a simple application.
For example, you might wish to use a document databae like RavenDB or Couch for your OLTP work, because it gives you the means to save your entities, and query those entities out into flattened projections across documents (single-query views). (RavenDB more than CouchDB, but that's neither here nor there ;-))
You could also use it for simple reporting, using Map/Reduce to give you some statistics for display on certain pages (popular products, tag clouds etc).
However, a lot of reporting systems are built to query relational stores, so you might want to replicate data into a reporting database.
For example, in RavenDB, you have the option to take any index, and automatically replicate the data in that index into a relational store.
It makes sense because having the data in a relational format means you can do complex cross-document queries and integrate with existing reporting products - without getting in the way of the standard OLTP work or the document database design.
This is just one answer out of many, because there are other examples where one particular sort of data store is more suited towards a specific purpose, at the end of the day there is no getting away from that. (Unless you believe the VoltDB guys)
除非您的操作规模使关系数据库根本无法工作，否则 NoSQL 的一大优势是易于开发 - 例如不需要 ORM 或数据库升级脚本。一旦您开始将 SQL 用于系统的某个部分，只需很少的额外工作即可将其用于其他部分。
几乎在任何项目中都会有更适合特定类型数据存储的组件。重要的问题是这种差异是否足以证明使用多个数据存储的开销是合理的。一般来说，这意味着规模、临时报告和数据结构的组合，无法很好地映射到关系数据库。
Unless you are operating at a scale where relational databases simply won't work, the big advantage of NoSQL is ease of development - things like not needing an ORM or database upgrade scripts. As soon as you start using SQL for one part of the system it takes very little additional effort to use it for other parts.
In just about any project there will be components that are more suited to a particular type of data store. The important question is whether the difference is enough to justify the overhead of using multiple data stores. Generally that means a combination of scale, ad hoc reporting and data structures that don't map well to a relational database.
NOSQL 可能用于从 SQL 数据存储复制数据。在这种情况下，我想从移动 SQLITE 记录创建文档，并依靠 couch 或 mongo 将其复制到服务器上的 nosql。然后，服务器 SQL 可以处理传入的文档。
NOSQL could possibly be used to replicate data from a SQL datastore. In this scenario i want to create documents from mobile SQLITE records, and rely on couch or mongo to replicate this to a nosql on the server. The server SQL can then process the incoming documents.
这实际上不是一个编程问题，但这就是我的想法。
如果您考虑 CAP 定理 http://en.wikipedia.org/wiki/CAP_theorem，您可以假设关系数据库关注一致性和可用性，而 NoSQL 关注可用性和分区容忍性（具有事件一致性）。
如果您希望 SQL 查询真正一致，那么您应该考虑使用 RDBMS。如果这不是先决条件，那么您可以使用 NoSQL 数据库。
这就是为什么大多数时候，最好的答案是同时使用两者，充分利用两者的优势。
It's not really a programming question but here is what I think.
If you consider the CAP theorem http://en.wikipedia.org/wiki/CAP_theorem, you could assume that Relationnal Databases focus on CONSISTENCY and AVAILABILITY while NoSQL focus on AVAILABILITY and PARTITION TOLERENCE (with EVENTUAL CONSISTENCY).
If you espect the SQL query to be really consistent then you should consider using a RDBMS. If it's not a pre-requisite, then you could use a NoSQL database.
That's why most of the time, the best answer it to use both, taking advantages of both.