何时使用CouchDB与RDBMS [英] When to use CouchDB vs RDBMS

问题描述

• 直观的REST / HTTP接口
  li>
  
• 轻松复制


• 将数据存储为文档而不是归一化表格

$ b b我知道这不是一个成熟的产品，所以应该谨慎采用，但我想知道它是否实际上是一个可行的替代RDBMS（尽管介绍页说，否则 - http://couchdb.apache.org/docs/intro.html ）。

1. 在什么情况下，CouchDB是比RDBMS（例如MySQL）更好的数据库选择。在可扩展性，设计+开发时间，可靠性和维护方面。


2. 是否还有RDBMS仍然是正确选择的情况？


3. 这是一个选择，还是作为最佳实践出现的混合解决方案？

解决方案

我最近参加了在伦敦的NoSQL会议，认为我现在有一个更好的主意，现在如何回答原来的问题。我还写了一个博客帖子，还有几个其他 good 。

要点：

• 积累了大约30年管理关系数据库的知识，所以不应该仔细考虑替换它们;非关系数据存储不如关系数据存储成熟，因此采用
固有的风险更大。

• 存在不同类型的非关系数据存储;一些是键值存储，一些是文档存储，一些是图表数据库。


• 您可以使用混合方法，例如。社交软件网站的RDBMS和图形数据存储的组合


• 文档数据存储（例如CouchDB和MongoDB）可能最接近关系数据库，并提供包含所有字段的JSON数据结构


• 非关系型数据库支持复制（包括（但不限于）主 - 主）;关系数据库也支持复制，但它可能不像非关系选项那么全面。


• 很大的网站，如Twitter，Digg和Facebook使用Cassandra，支持聚类


• 关系数据库可能适用于90％的案例

似乎是谨慎行事。

I am looking at CouchDB, which has a number of appealing features over relational databases including:

• intuitive REST/HTTP interface
• easy replication
• data stored as documents, rather than normalised tables

I appreciate that this is not a mature product so should be adopted with caution, but am wondering whether it is actually a viable replacement for an RDBMS (in spite of the intro page saying otherwise - http://couchdb.apache.org/docs/intro.html).

1. Under what circumstances would CouchDB be a better choice of database than an RDBMS (e.g. MySQL), e.g. in terms of scalability, design + development time, reliability and maintenance.
2. Are there still cases where an RDBMS is still clearly the right choice?
3. Is this an either-or choice, or is a hybrid solution more likely to emerge as best practice?

解决方案

I recently attended the NoSQL conference in London and think I have a better idea now how to answer the original question. I also wrote a blog post, and there are a couple of other good ones.

Key points:

• We have accumulated probably 30 years knowledge of adminstering relational databases, so shouldn't replace them without careful consideration; non-relational data stores are less mature than relational ones, and so are inherently more risky to adopt
• There are different types of non-relational data store; some are key-value stores, some are document stores, some are graph databases
• You could use a hybrid approach, e.g. a combination of RDBMS and graph data store for a social software site
• Document data stores (e.g. CouchDB and MongoDB) are probably the closest to relational databases and provide a JSON data structure with all the fields presented hierarchically which avoids having to do table joins, and (some might argue) is an improvement on the traditional object-relational mapping that most applications currently use
• Non-relational databases support replication (including master-master); relational databases support replication too but it may not be as comprehensive as the non-relational option
• Very large sites such as Twitter, Digg and Facebook use Cassandra, which is built from the ground up to support clustering
• Relational databases are probably suitable for 90% of cases

In summary, consensus seems to be "proceed with caution".

这篇关于何时使用CouchDB与RDBMS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！