RDBMS是不足够的

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

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

　　像引用完整性、约束、原子更新这些特性在客户机—服务器的世界里非常重要，但在服务的世界里它们是无意义的。
而这些都是面向文档的分布式数据库（Document Oriented Distributed Databases）着重打算解决的典型问题。

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

保存（Save）：?荼４姹匦胧前踩??碅CID）、持久且高效的。
观察（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版。已经有些人对修订用户界面部分的代码表示了兴趣，我们看看结果会怎样。