65

我在看 CouchDB，它比关系数据库有许多吸引人的特性，包括：

  • 直观的 REST/HTTP 接口
  • 容易复制
  • 数据存储为文档，而不是规范化的表格

我很欣赏这不是一个成熟的产品，因此应该谨慎采用，但我想知道它是否真的是 RDBMS 的可行替代品（尽管介绍页面另有说明 - http://couchdb.apache.org/docs /intro.html )。

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

7 回答 7

48

我最近参加了在伦敦举行的 NoSQL 会议，并认为我现在对如何回答最初的问题有了更好的想法。我还写了一篇博文，还有其他几篇不错 的。

关键点：

  • 我们在管理关系数据库方面积累了大约 30 年的知识，因此不应在没有仔细考虑的情况下替换它们；非关系型数据存储不如关系型数据存储成熟，因此采用起来风险更大
  • 有不同类型的非关系数据存储；有些是键值存储，有些是文档存储，有些是图形数据库
  • 您可以使用混合方法，例如将 RDBMS 和图形数据存储组合用于社交软件站点
  • 文档数据存储（例如 CouchDB 和 MongoDB）可能是最接近关系数据库的，并提供 JSON 数据结构，所有字段都分层呈现，避免了表连接，并且（有些人可能会争辩）是对传统对象的改进——大多数应用程序当前使用的关系映射
  • 非关系型数据库支持复制（包括master-master）；关系数据库也支持复制，但它可能不如非关系选项全面
  • Twitter、Digg 和 Facebook 等非常大的网站使用 Cassandra，它是从头开始构建以支持集群的
  • 关系数据库可能适用于 90% 的情况

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

于 2010-04-28T16:09:35.113 回答
26

在有人给出更深入的答案之前，这里有一些 CouchDB 的优缺点

优点：

  • 您不需要将数据放入那些讨厌的高阶范式之一
  • 您可以随时更改数据的“架构”
  • 您的数据将为您的查询准确编入索引，因此您将在恒定时间内获得结果。

缺点：

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

优点或缺点：

  • 创建视图不像在 SQL 中那么简单，它更像是解决难题。取决于你的类型，如果这是一个赞成或反对:)
于 2009-08-20T16:09:42.237 回答
13

CouchDB 是几个可用的“键/值存储”之一，其他包括像BDB这样的老东西，像Persevere、MongoDB和 CouchDB这样的面向 Web 的数据库，像memcached（仅 RAM）和Tokyo Cabinet这样的新的超快速存储，以及像 Hadoop 这样的大型存储和 Google 的 BigTable（MongoDB 也声称在这个领域）。

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

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

我看到的当前主题是在“Rails doesn't scale!!”之后 害怕，现在很多人意识到这与您的 Web 框架无关；但是关于智能缓存，以避免在可能的情况下访问数据库，甚至是 webapp。那里的后起之秀是memcached。

与往常一样，这一切都取决于您的需求。

于 2009-08-20T16:16:49.320 回答
7

这是一个很难回答的问题。因此，我将尝试强调 CouchDB 可能对您不利的领域。

人们在 Couch Users 和 Dev 邮件列表中遇到的两个最大困难是：

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

Couch Views 本身就是一座孤岛。如果您需要聚合/合并/交叉一组视图，您现在几乎必须在应用程序层中这样做。您可以使用视图排序规则和复杂键来帮助连接一些技巧，但这些技巧仅适用于某些类型的数据。对于不同的应用程序，这可能适合也可能不适合。话虽如此，这个问题可以通过不同的数据结构来减少或消除。

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

要记住的另一件事是，很多时候您可能需要合并/合并/相交的数据将是您无论如何都将在 RDBMS 数据库中离线执行的数据，因此您可能不会因为在 CouchDB 中执行相同操作而丢失任何东西。

简短的回答：我认为最终 CouchDB 将能够处理你想抛出的任何类型的问题。但是您使用它的舒适度可能因开发人员而异。我觉得这有点主观。我碰巧喜欢使用图灵完备的语言来查询我的数据，并在应用层保留更多的逻辑。你的旅费可能会改变。

于 2009-08-25T02:50:57.820 回答
3

山姆，您必须对 CouchDB 采取另一种方法，通常使用基于地图或文档的数据库。您无法定义约束，例如唯一性，但您可以查询数据以检查是否使用了该电子邮件以及是否也使用了该登录名。这是正确的方法，你必须改变主意。

于 2010-02-19T05:09:23.757 回答
2

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

于 2009-08-26T12:46:08.457 回答
0

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

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

于 2009-08-20T16:12:15.633 回答