RDBMS 是不足够的

尽管关系数据库适合客户机—服务器模型，但在服务的世界里我们需要新的方案。RDBMS 受挫于伸缩性问题：如何实现冗余和并行？

[关系数据库] 成了单点故障的所在。尤其复制（replication）是不可忽视的。要理解其原因，请考虑在两台数据库服务器之间保持数据完全一致的问题。如果两台都读和写数据，那么很难同步变化。如果设为一主一从也不好，因为当用户写入信息时，主数据库要独自承受全部的负荷。

而且，Assaf Arkin 还认为写一致性（write consistency）是 RDBMS 自己把自己压垮的原因。

像引用完整性、约束、原子更新这些特性在客户机—服务器的世界里非常重要，但在服务的世界里它们是无意义的。

而这些都是面向文档的分布式数据库（Document Oriented Distributed Databases）着重打算解决的典型问题。

MySQL 的软件工程师 Damien Katz 介绍了数据管理的四大支柱：

• 保存（Save）：数据保存必须是安全（即 ACID）、持久且高效的。
• 观察（See）：数据应当易于获取，集成了简单的报表方法。并提供（全文）搜索。
• 安全（Secure）：对数据分割隔离（Compartmentalization），允许 SSL 连接，给数据分配用户、组和角色……
• 分担（Share）：成为分布式的，在线或者离线。

Damien 使用 CouchDB 实现了这 4 大支柱。

CouchDB 是：

• 文档数据库服务器，可通过 RESTful JSON API 访问。
• 为特殊目的而设计的，无 Schema 且地址空间是平坦的。
• 分布式的，可执行健壮的增量复制，具备双向的冲突检测及管理。
• 可查询，可索引，具有一个面向数据表的报表引擎，使用 JavaScript 作为引擎的查询语言。

CouchDB 不是：

• 关系数据库。
• 对关系数据库的替代。
• 面向对象的数据库。更具体地说，CouchDB 不打算成为 OO 编程语言的无缝持久化层。

将文档插入到数据库中，然后再为查询定义视图，在这样的想法和 CouchDB 的启发下， Anthony Eden 动手写出了他自己的面向文档数据库： RDDB 。已经有人对 RDDB 进行了详尽的评议。

RDDB 目前的特性有：

• 文档只是简单的名称 / 值对的集合。
• 可用 Ruby 代码定义视图。
• 可定义一个缩减块（reduce block）来缩减视图的初始映射数据。
• 视图可被实体化（materialized）以提高查询的性能。
• 数据存储 / 视图存储 / 实体化存储都是可插拔的。当前的实现包括 RAM、分区文件 / 文件系统和 Amazon S3。
• 分布式实体化（materialization）已经可用，不过即将重写。

InfoQ 有幸与 Anthony 讨论 RDDB、CouchDB 和 RDBMS。

首先，是什么让你开始开发 RDDB，在 Rejectconf 上你提过一个研究项目？

我把 RDDB 看作是个人的研究项目。在过去的一年中我的工作大量地牵扯到分析型系统（analytical system），开发数据仓库这一类内容。我也在使用 Amazon 的 Web 服务。RDDB 有望帮我把这两者在一定程度上结合起来，这样我就能够得到一个在 EC2 和 S3 上运行的分析型数据库（analytical database）。这是我主要目标，也是创作 RDDB 的推动因素。

你在日常工作中经常接触数据集成的问题；你觉得面向文档的分布式数据库现在应用得过少吗？今后会应用得越来越多吗？

我不确定。关系数据库的历史悠久，它们在长时间里已经变得很成熟。一方面它们在实践中是一个明显的选择，因为它们是可信赖的。另一方面关系数据库不一定对于所有类型的数据存储和查找都是最佳的选择，因此新型的数据存储是有机会的。我只是不确定面向文档数据库是否就是我们寻找的新型数据库——我想在很大程度上要取决于它的伸缩性，和处理海量文档时不出现性能退化的能力。

在服务的世界中是否仍有 RDBMS 的一席之地？引用完整性、原子更新和约束在客户机—服务器的世界里有其价值，但在服务的世界中，它们是否仍然有意义呢？

RDBMS 仍然是我们评价其他东西的标杆，因此我不认为关系数据库的地位会在短时间内发生什么变化。我想最终我们会超越对原子更新的需要，只要数据库能够把暂时性作为常态，就能消除对任何更新的需要。如果我们能迁移到一种环境下，在其中所有绝对必须的东西都包含在资源里面，同时系统对失效的链接变得更加宽容，在这样的环境下引用完整性就不需要了。约束可能一直都会有用，如果能为约束定义逻辑，它们甚至会变得更加强大。

你如何比较 RDDB 和 CouchDB？（我明白 RDDB 还处在一个很早期的开发阶段，CouchDB 也一样。）使用 RDDB 比起使用 CouchDB Ruby 绑定有什么优势？

我可以一起回答这两个问题。CouchDB 使用 Erlang 编写的，而 RDDB 是用 Ruby 编写的，因此 Ruby 开发者会觉得 RDDB 更方便自己动手摆弄。CouchDB 用了 Erlang 的语言特性来在分布式处理中进行进程间通信，而 Ruby 要依赖 Rinda、Ruby SQS 之类的库。对于 Ruby 开发者来说，让 RDDB 运行起来显然比 CouchDB 要容易得多，因为只需要通过 RubyGems 安装 RDDB 就行了。RDDB 的视图是用 Ruby 写的，而 CouchDB 视图是 JSON（至少目前如此）。我认为就现在的情况 RDDB 更容易插拔各种不同的文档存储、视图存储和实体化存储实现（全都支持 RAM、文件系统和 S3 存储）。RDDB 拥有不同的实体化实现（比如本地、Rinda 和 RC2），而且还有线程化和非线程化的实体化器（materializers）。

我们不久前写过一篇文章介绍 ActiveWarehouse ，那个项目进行得怎么样了？它有被用到企业环境中吗？

ActiveWarehouse 最近没什么动静。我认为大多数工作和用途都是在 ETL 那边，也就是 ActiveWarehouse ETL 库。我的目标是在不久的将来发布 ActiveWarehouse ETL 的 1.0 版。至于 Rails 插件，它绝对需要先改善一下显示方面，才能前进到 1.0 版。已经有些人对修订用户界面部分的代码表示了兴趣，我们看看结果会怎样。

查看英文原文： The RDBMS is not enough.