我正在研究CouchDB,它在关系数据库上有许多吸引人的功能,包括:
直观的REST/HTTP接口
轻松复制
数据存储为文档,而不是标准化表
我知道这不是一个成熟的产品,所以应谨慎采用,但我想知道它是否真的是一个可行的替代RDBMS(尽管介绍页面说不然 - http://couchdb.apache.org/docs /intro.html).
在什么情况下CouchDB比RDBMS(例如MySQL)更好地选择数据库,例如在可扩展性,设计+开发时间,可靠性和维护方面.
是否还存在RDBMS显然仍然是正确选择的情况？
这是一种选择还是选择,还是更有可能成为最佳实践的混合解决方案？
Andrew White.. 45
我最近参加了伦敦的NoSQL会议,并认为我现在更好地了解如何回答原始问题.我还写了一篇博文,还有其他几篇好 文章.
关键点:
我们已经积累了大约30年的管理关系数据库的知识,所以不应该在没有仔细考虑的情况下取代它们; 非关系数据存储不如关系数据存储成熟,因此采用的风险更大
存在不同类型的非关系数据存储; 一些是键值存储,一些是文档存储,一些是图形数据库
您可以使用混合方法,例如,社交软件站点的RDBMS和图形数据存储的组合
文档数据存储(例如CouchDB和MongoDB)可能是最接近关系数据库的,它提供了一个JSON数据结构,其中所有字段都是分层显示的,这避免了必须进行表连接,并且(有些人可能认为)是对传统对象的改进 - 大多数应用程序当前使用的关系映射
非关系数据库支持复制(包括master-master); 关系数据库也支持复制,但它可能不如非关系选项那么全面
非常大的网站,如Twitter,Digg和Facebook使用Cassandra,它是从头开始构建的,以支持群集
关系数据库可能适用于90%的情况
总之,共识似乎是"谨慎行事".
我最近参加了伦敦的NoSQL会议,并认为我现在更好地了解如何回答原始问题.我还写了一篇博文,还有其他几篇好 文章.
关键点:
我们已经积累了大约30年的管理关系数据库的知识,所以不应该在没有仔细考虑的情况下取代它们; 非关系数据存储不如关系数据存储成熟,因此采用的风险更大
存在不同类型的非关系数据存储; 一些是键值存储,一些是文档存储,一些是图形数据库
您可以使用混合方法,例如,社交软件站点的RDBMS和图形数据存储的组合
文档数据存储(例如CouchDB和MongoDB)可能是最接近关系数据库的,它提供了一个JSON数据结构,其中所有字段都是分层显示的,这避免了必须进行表连接,并且(有些人可能认为)是对传统对象的改进 - 大多数应用程序当前使用的关系映射
非关系数据库支持复制(包括master-master); 关系数据库也支持复制,但它可能不如非关系选项那么全面
非常大的网站,如Twitter,Digg和Facebook使用Cassandra,它是从头开始构建的,以支持群集
关系数据库可能适用于90%的情况
总之,共识似乎是"谨慎行事".
在有人给出更深入的答案之前,以下是CouchDB的一些优缺点
优点:
您不需要将数据放入其中一个讨厌的高阶正规形式中
您可以随时更改数据的"架构"
您的数据将完全针对您的查询编制索引,因此您将获得恒定时间的结果.
缺点:
您需要为每个查询创建视图,即ad-hoc类似查询(例如在SQL中连接动态WHERE和SORT)查询不可用.
您将拥有冗余数据,或者您将最终在"客户端"自己实现连接和排序逻辑(例如,在多个字段上排序多对多关系)
优点或缺点:
创建视图并不像SQL那样简单,它更像是解决难题.取决于你的类型,如果这是一个专业或骗局:)
CouchDB是几个可用的"键/值存储"之一,其他包括像BDB这样的老东西,像Persevere,MongoDB和CouchDB 这样的面向Web的东西,像memcached(仅限RAM)和东京内阁这样的超级快速,以及像Hadoop这样的大型商店.和谷歌的BigTable(MongoDB也声称在这个领域).
键/值存储和关系数据库肯定有空间.传统上,大多数RDB被认为是键/值之上的层.例如,MySQL曾经使用BDB作为表的可选后端.简而言之,键/值对字段和关系一无所知,它们是SQL的基础.
键/值存储通常更容易扩展,这使得它们在爆炸式增长时成为一个有吸引力的选择,就像Twitter一样.当然,这意味着必须在代码上管理存储值之间的任何关系,而不是仅在SQL中声明.CouchDB的方法是在值部分存储大的"文档",使它们(大部分)自包含,因此您可以在单个查询中获得大部分所需的数据.许多用例符合这个想法,有些则没有.
我看到的当前主题是"Rails无法扩展!!"之后 恐慌,现在很多人都意识到这不是关于你的网络框架; 但关于智能缓存,以避免在可能的情况下访问数据库,甚至是webapp.那里的后起之秀是memcached.
一如既往,这一切都取决于您的需求.
这是一个难以回答的问题.因此,我将尝试强调CouchDB可能对您不利的区域.
人们拥有的Couch Users和Dev邮件列表的两个最大难点是:
复杂的数据连接.
多步映射/减少.
Couch Views几乎都是岛屿.如果您需要聚合/合并/交叉一组视图,那么您现在必须在应用程序层中这样做.您可以使用视图排序和复杂键来帮助进行连接,但这些技巧仅适用于某些类型的数据.对于不同的应用,这可能适合也可能不适合.多次说这个问题可以通过不同的方式构建数据来减少或消除.
其他人对这个问题的评论展示了一些非常适合CouchDB的不同类型的数据.
另外要记住的一点是,很多时候你可能需要组合/合并/交叉的数据是你在RDBMS数据库中离线的数据,所以你可能不会在CouchDB中做同样的事情而丢失任何东西.
简答:我认为CouchDB最终能够处理你想要抛出的任何问题.但是,您使用它的舒适程度可能因开发人员而异.我认为这有点主观.我碰巧喜欢使用turing完整语言来查询我的数据并在应用程序层中保留更多逻辑.你的旅费可能会改变.
京公网安备 11010802040832号 | 京ICP备19059560号-6 