何时使用CouchDB与RDBMS

Question

我正在研究CouchDB，它在关系数据库方面具有许多吸引人的功能，包括：

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

我理解这不是一个成熟的产品，所以应谨慎采用，但我想知道它是否真的是RDBMS的可行替代品（尽管介绍页面另有说法 - http://couchdb.apache.org/docs/intro.html）。

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

Answer 1

我最近参加了伦敦的NoSQL会议，并认为我现在更好地了解如何回答原始问题。我还写了blog post，还有其他几个good ones。

关键点：

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

总之，共识似乎是“谨慎行事”。

Answer 2

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

优点：

• 您不需要将数据放入其中一个讨厌的高阶正常形式
• 您可以随时更改数据的“架构”
• 您的数据将完全针对您的查询编制索引，因此您将在固定时间内获得结果。

缺点：

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

优点或缺点：

• 创建视图并不像SQL那样简单，它更像解决难题。取决于您的类型，如果这是专业人士或骗子：）

Answer 3

CouchDB是几个可用的'键/值存储'之一，其他包括像BDB这样的老手机，像Persevere，MongoDB和CouchDB这样的面向网络的老店，新的超快速memcached（仅限RAM）和Tokyo Cabinet，以及像Hadoop和Google的BigTable这样的大型商店（MongoDB也声称在这个领域）。

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

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

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

一如既往，这一切都取决于您的需求。

Answer 4

这是一个难以回答的问题。因此，我将尝试突出显示CouchDB可能对您不利的区域。

人们拥有的Couch用户和开发人员邮件列表的两个最大困难来源是：

• 复杂的数据连接。
• 多步图/缩小。

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

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

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

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

Answer 5

Sam你必须使用CouchDB和一般的地图或基于文档的数据库。您无法定义约束，例如唯一，但您可以查询数据以检查是否使用了该电子邮件以及是否也使用了该登录。这是正确的approch，你必须改变主意。

Answer 6

如果我错了，请纠正我。当您需要验证多个字段的文档的唯一性时，Couchdb是无用的。例如，不可能强制执行验证规则，例如“登录和电子邮件都必须是唯一的”并保持数据处于混合状态。您可以在保存文档之前检查，但有人可以在您之前推送并且数据变得不一致。

Answer 7

如果您正在处理只有浅层数据层次结构的表格数据，那么RDBMS系统可能是您的最佳选择。这是RDBMS系统的主要用途，文档和工具支持非常好。

对于像xml这样的嵌套数据，文档数据库应该能够更快地访问您的数据。此外，存储模型更接近于数据，因此检索应该更直接。