Erlang-China

Peter :
我最不能忍受的,即CouchDB仅支持HTTP REST接口,这对性能是个致命的约束

在我看来，对于 CouchDB 而言，HTTP REST 与其说是致命的约束，还不如说是成功的法宝。

相比 Binary 的协议，对于单一连接的通讯效率而言，HTTP 确有 Trade Off，但，HTTP 是无连接协议，因而更具可扩展性(Scalable)。而且，几乎所有的语言都已经内置对 HTTP 协议的支持，无需再做通讯层的包装(于推广有利)。基本上，这就是一个设计决策问题：用单连接通讯效率的相对低下换取支持连接数量上的增加。

实际上，从 CouchDB 所设想的应用场景来看。服务端是 CouchDB + App Code 而它所设计面对的客户端，在很大程度上，直接就是浏览器(或者是程序扮演的浏览器)。以这个“主要应用场景”的角度来说，在性能特性上，显然与 HTTP 要解决的问题完全一致。因而，“基于 HTTP”的设计决策，正是理所应当之事。

我们可以设想，如果 CouchDB 和另外的 Key-Value 存储机制一样，也采用 binary 协议，那么肯定会有一堆开发者来抱怨没有语言原生的接口可用。又或者，作为一个开源项目，因为这个对浏览器不友好的“缺点”，使它仅仅适用于一些特定场合(比如，被当做 MemoryCache 来用)，湮灭在大量的同类项目之中，根本就无法达到现有的知名程度，这也亦未可知。

对于性能担忧的解决方案是：客户端的批量模式(One Request Multiple Documents)和服务端的水平扩容(加机器)。对无连接协议(单向通讯)不适的解决方案是，长连接(Comet)。两者都容易理解，无须再做解释。妙的是，这两者几乎都是标准的 HTTP 方式，仍然保持了对于浏览器最大程度上的兼容。

可以设想一幅这样的应用场景：

任何一台裸机(移动设备或者 PC)，只需装上 OS + CouchDB + Browser 即可(CouchDB 和 Firefox 都已经是 Ubuntu 的预安装包)，象上网本一样，硬件最小化预装。

当我们需要应用的时候，可以经 Browser 进入由 CouchDB 加持的 App Store 页面，选择所需应用，安装到本地的 CouchDB 上(程序以 Couch 文档同步的方式安装到本机)，并且可以保持软件的同步升级。

此后，在本地的 localhost 上就可以使用这些应用，数据保存在本地的 CouchDB 之中，离线而且高速。

如果需要数据的同步和备份，通过一个账户系统，就可以将本地的数据(和程序)同步到“云端”的 CouchDB 服务器上，这个同步过程，既可以是随时的(比如 SNS应用)，也可以是偶尔的(比如 PDA设备)，既可以是显式同步(比如 协作场景)，也可以是后台同步(比如 照片管理)。只要使用同一个同步账户，完全可以在另外一台机器上，随时恢复工作场景和数据，继续此前的工作。

相比 Java 描绘的 Write Once Run Anywhere 。CouchApp 集合了 Web 无所不在的亲切界面与 MVCC 无不同步的威力。在我看来，它所描绘的应用场景，更为诱人。

fan :
数据库替代app server？这个东西太强大了点吧，不不了解，只是我对试图一统江湖的东西都有点拒绝

这位 fan 兄弟的逻辑好奇怪哦 —— 不了解，您又是怎样知道它的意图是想要一统江湖呢？

虽说被称作 db 但 couchdb 绝对不是传统意义上的 db 。它几乎所有的特性都是建立在 http 之上的：restful 的文档和附件 api，server-side 的 javascript query engine，基于 http 的数据库同步……，作为一个 http-only 的 doc db 这些都是 couchdb 的基本配备。

而，从一个 web 开发者的角度来看，这样的特性组合，距离一个专门针对于 ajax web 应用的 app server 其实已经相差不远。所欠缺的大概只有这么几个部分：URL Mapping、用户认证与权限机制、Document Transform 机制、以及一个合乎潮流而且易于使用的 web 开发框架。这些对于 hacker 级的开发者而言，没有难度，而 couchdb 也是开源的，如果官方团队不做，相信会有很多第三方团队乐于填补这一空白。

couchdb 并未加持什么火箭科技，究其本质而言，它所带来的只是“建立在 http 基础之上的 mvcc 同步”而已，所谓的离线 web 我们也可以将其理解为 localhost web app + 远程同步的一个新称呼，技术本身并没有什么值得稀奇的地方。如果说一统江湖，一时之间，我还真是不知这是从何说起。