何时使用 CouchDB 与 RDBMS [关闭]

Posted 2023-02-16

【中文标题】何时使用 CouchDB 与 RDBMS [关闭]

【英文标题】：When to use CouchDB vs RDBMS [closed]

【发布时间】：2010-11-21 09:10:18

【问题描述】：

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

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

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

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

【参考方案1】：

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

优点：

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

缺点：

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

优点或缺点：

创建视图不像在 SQL 中那样简单，它更像是解决难题。取决于你的类型，这是一个专业还是一个缺点:)

【讨论】：

自从提出这个问题以来，我一直在查看其他来源，在我看来，使用 CouchDB 的主要好处是它的“真实世界”数据表示与更传统的 RDBMS。请参阅books.couchdb.org/relax/intro/why-couchdb 以获得进一步的解释。我认为我提出的其他问题尚无答案。

【参考方案2】：

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

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

【讨论】：

RDBMS 系统目前支持 NoSQL 用于非结构化数据和文档。所以我不确定使用 Couchdb 有什么好处。

这个问题已经 12 岁了。

【参考方案3】：

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

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

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

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

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

【讨论】：

您讨论了这个问题，但您没有尝试回答。

couchdb 不是传统理解中的键值存储。 mongo 和 couch 都是面向文档的数据库。

【参考方案4】：

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

人们在 Couch 用户和开发者邮件列表中遇到的两个最大困难是：

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

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

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

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

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

【参考方案5】：

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

【讨论】：

CouchDB 确实有强制唯一性的方法。不过，这一切都处于关键水平。如果您需要登录名和电子邮件都是唯一的，那么只需从中派生文档 ID，您将永远无法在数据库中插入重复的登录名和电子邮件。它不同但同样有效。

考虑 2 个键：“[e-mail]”和“[e-mail]”。两个用户都有相同的电子邮件地址 [e-mail]。

选择一个作为“主”唯一键并将其用于主文档。然后创建一个以另一个为关键的辅助文档。它唯一的其他数据是主密钥。例如，选择电子邮件为主，所以用户名是次要的。使用密钥“[e-mail]”和其他任何数据创建一个文档，但还没有用户名。如果成功，请创建另一个带有“john”键的文档并将其存储在“[e-mail]”中。如果成功，它们都是唯一的，您可以使用键“[e-mail]”更新文档以将用户名设置为“john”。如果失败，请向用户询问其他用户名。

您还可以散列用户+电子邮件并将其用作密钥。如果查询返回任何结果，则它不是唯一的。

显然散列是可行的方法，但您需要分别对用户和电子邮件进行散列以保证每个都是唯一的。

【参考方案6】：

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

【参考方案7】：

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

关键点：

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

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

【讨论】：

也感谢您发布的精彩博客。总结了一些很好的意见。

我想挑战 use-because-mature 的说法。众所周知，旧项目往往一团糟。那么，为什么不采用具有良好设计的新软件呢？我想说的是，ACID 合规性是数据存储的一个重要参数，但即便如此，也可以通过适当的代码策略进行辩论。在 RDBMS 中管理、扩展和恢复备份是痛苦和烦人的，CouchDB 在这方面要容易得多。通常的主要权衡决策是在速度和完整性之间做出权衡，但随着 NoSQL 系统的快速发展，这条线变得不那么清晰了。