何时使用CouchDB与RDBMS

And*_*use 63 database rdbms couchdb

我正在研究CouchDB,它在关系数据库上有许多吸引人的功能,包括:

  • 直观的REST/HTTP接口
  • 轻松复制
  • 数据存储为文档,而不是标准化表

我知道这不是一个成熟的产品,所以应谨慎采用,但我想知道它是否真的是一个可行的替代RDBMS(尽管介绍页面说不然 - http://couchdb.apache.org/docs /intro.html).

  1. 在什么情况下CouchDB比RDBMS(例如MySQL)更好地选择数据库,例如在可扩展性,设计+开发时间,可靠性和维护方面.
  2. 是否还存在RDBMS显然仍然是正确选择的情况?
  3. 这是一种选择还是选择,还是更有可能成为最佳实践的混合解决方案?

And*_*use 45

我最近参加了伦敦的NoSQL会议,并认为我现在更好地了解如何回答原始问题.我还写了一篇博文,还有其他几篇好 文章.

关键点:

  • 我们已经积累了大约30年的管理关系数据库的知识,所以不应该在没有仔细考虑的情况下取代它们; 非关系数据存储不如关系数据存储成熟,因此采用的风险更大
  • 存在不同类型的非关系数据存储; 一些是键值存储,一些是文档存储,一些是图形数据库
  • 您可以使用混合方法,例如,社交软件站点的RDBMS和图形数据存储的组合
  • 文档数据存储(例如CouchDB和MongoDB)可能是最接近关系数据库的,它提供了一个JSON数据结构,其中所有字段都是分层显示的,这避免了必须进行表连接,并且(有些人可能认为)是对传统对象的改进 - 大多数应用程序当前使用的关系映射
  • 非关系数据库支持复制(包括master-master); 关系数据库也支持复制,但它可能不如非关系选项那么全面
  • 非常大的网站,如Twitter,Digg和Facebook使用Cassandra,它是从头开始构建的,以支持群集
  • 关系数据库可能适用于90%的情况

总之,共识似乎是"谨慎行事".

  • 也感谢您发布的精彩博客。总结了一些很好的意见。 (2认同)

Zed*_*Zed 26

在有人给出更深入的答案之前,以下是CouchDB的一些优缺点

优点:

  • 您不需要将数据放入其中一个讨厌的高阶正规形式中
  • 您可以随时更改数据的"架构"
  • 您的数据将完全针对您的查询编制索引,因此您将获得恒定时间的结果.

缺点:

  • 您需要为每个查询创建视图,即ad-hoc类似查询(例如在SQL中连接动态WHERE和SORT)查询不可用.
  • 您将拥有冗余数据,或者您将最终在"客户端"自己实现连接和排序逻辑(例如,在多个字段上排序多对多关系)

优点或缺点:

  • 创建视图并不像SQL那样简单,它更像是解决难题.取决于你的类型,如果这是一个专业或骗局:)


Jav*_*ier 13

CouchDB是几个可用的"键/值存储"之一,其他包括像BDB这样的老东西,像Persevere,MongoDB和CouchDB 这样的面向Web的东西,像memcached(仅限RAM)和东京内阁这样的超级快速,以及像Hadoop这样的大型商店.和谷歌的BigTable(MongoDB也声称在这个领域).

键/值存储和关系数据库肯定有空间.传统上,大多数RDB被认为是键/值之上的层.例如,MySQL曾经使用BDB作为表的可选后端.简而言之,键/值对字段和关系一无所知,它们是SQL的基础.

键/值存储通常更容易扩展,这使得它们在爆炸式增长时成为一个有吸引力的选择,就像Twitter一样.当然,这意味着必须在代码上管理存储值之间的任何关系,而不是仅在SQL中声明.CouchDB的方法是在值部分存储大的"文档",使它们(大部分)自包含,因此您可以在单个查询中获得大部分所需的数据.许多用例符合这个想法,有些则没有.

我看到的当前主题是"Rails无法扩展!!"之后 恐慌,现在很多人都意识到这不是关于你的网络框架; 但关于智能缓存,以避免在可能的情况下访问数据库,甚至是webapp.那里的后起之秀是memcached.

一如既往,这一切都取决于您的需求.

  • 您讨论了这个问题,但您没有尝试回答它. (7认同)
  • couchdb 不是传统理解中的键值存储。mongo 和 couch 都是面向文档的数据库。 (2认同)

Jer*_*all 7

这是一个难以回答的问题.因此,我将尝试强调CouchDB可能对您不利的区域.

人们拥有的Couch Users和Dev邮件列表的两个最大难点是:

  • 复杂的数据连接.
  • 多步映射/减少.

Couch Views几乎都是岛屿.如果您需要聚合/合并/交叉一组视图,那么您现在必须在应用程序层中这样做.您可以使用视图排序和复杂键来帮助进行连接,但这些技巧仅适用于某些类型的数据.对于不同的应用,这可能适合也可能不适合.多次说这个问题可以通过不同的方式构建数据来减少或消除.

其他人对这个问题的评论展示了一些非常适合CouchDB的不同类型的数据.

另外要记住的一点是,很多时候你可能需要组合/合并/交叉的数据是你在RDBMS数据库中离线的数据,所以你可能不会在CouchDB中做同样的事情而丢失任何东西.

简答:我认为CouchDB最终能够处理你想要抛出的任何问题.但是,您使用它的舒适程度可能因开发人员而异.我认为这有点主观.我碰巧喜欢使用turing完整语言来查询我的数据并在应用程序层中保留更多逻辑.你的旅费可能会改变.