Introducing… CouchDB!
pi1ot 同学提了一个问题：
javaeye上看到的“用Erlang开发的文档数据库系统CouchDB”是个什么东西，啥叫文档数据库啊
这是一个好问题，因为我也老见到这个名字，但总不知其所以然，因此，特地作了一下 research ，将我了解到的，与诸君共享。
啥叫文档数据库？
CouchDB FAQ 里面这么写：
A CouchDB document is an object that consists of named fields. Field values are lists that may contain strings, numbers and dates.
晕啊，这段虫族文翻过来，我大致这么理解：它是一个数据库，它的里面存放文档。没了！怎么能没了呢？是的，它就是没了，没有 schema， 没有 table， 没有 record，也没有 sql 。就是这样的数据库了，抓狂去吧。哈哈。其实，这个玩意并不罕见。
从概念上，和 Erlang 的 dict ，或者 Java/.Net 的 hashmap ，以及 Oracle 收购的 BerkleyDB可以模糊糊糊的看作一类东西。尤其是你用自己的生物 CPU 把 XML 和 Json 或者 Term 都模糊为“数据”的话。
HaHa，就是一个大 Hash ！
那么，CouchDB 是个什么东西？
首先 couchDB 的 couch 是 Cluster Of Unreliable Commodity Hardware 的缩写，即“由不可靠的廉价硬件组成集群”（是不是听起来似曾相识呢？没错，google 提起自己的核心技术的时候，也常常这么说），单就名字而言，就能嗅到野心勃勃的味道。这个计划是由 Mysql 的工程师 Damien Katz发起的。目前，它的核心特性包括：
- a REST API using JSON instead of XML for data transport,
- a JavaScript view engine based on Mozilla Spidermonkey,
- a GNU Autotools build system supporting most POSIX systems (Noah Slater) ,
- a built-in administration interface (Christopher Lenz),
- experimental fulltext search with Lucene (Jan Lehnardt) and
- countless tweeks, enhancements and other small refinements.
如果这个列表看的你一头雾水，那太正常了，我也是哦。这里核心的关键词是 —— Json ！没错，就是这个东西。所以，看到如下的 related project 列表就不足为奇了：
* CouchObject (Ruby client + JsServer for views in Ruby)
* CouchDb-Ruby
* CouchDB4J Java bindings
* Levitz – XUL based CouchDb utility client
* Erlang interface to CouchDB
* Perl interface, Net::CouchDb
* CouchDB Python Library
* CouchDB Common Lisp Library
* jQuery CouchDB Library
* Another PHP library for CouchDb
换句话说，如果以 CouchDB 为 DB ，那么你几乎可以用星球上的任何一种语言来访问它。而且，如果你语言恰好不支持（如果连 Http/Json 都不支持，我很怀疑这样的语言可以做什么用），你很快就能自己写一个出来。
其次，呃……，没有其次了（想必 Replication RESTful JavaScript Lucene 这些关键词你早已耳熟能详不用我废话了 ）。
畅想下，一个特别 2.0 的技术小组，借助 CouchDB 仅仅用到 Javascript （CouchDB 就是 DB ，其中的 Javascript view 就是 SQL，Javascript json 就是 Protocol，界面？莫不是 Javascript + HTML 的一颗小菜？）就能在 CouchDB 之上，通过“纯Javascript的方式”搞出一个巨复杂的 Web 2.0 应用，开发速度以小时计哇，什么 Ror Zend ErlyWeb 的统统无视（都没有数据表，搞那些浪费生命的劳什子做甚？）。哈哈……。《如来神掌》之Web开发版秘籍在此，5毛一本。
那么，和 Erlang 有什么关系？
呃，没有说么？CouchDB 是用 Erlang 写的。实际上，还有 C(SpiderMonkey) 。
其他
关于 couchDB，infoq 有一篇很不错的介绍文章（RDBMS is not Enough）（中文翻译）。其中还提到了RDDB，是一个 CouchDB 的 Ruby 跟随项目 。
一头雾水变成半头雾水，其实我最兴趣的是他为什么说“性能更高”？仅仅是erlang版的bdb或者memcached吗？在他的code网站上找不到文档，代码暂时也没时间分析（其实是我的erlang语法还不过关…）
晕死，咱们对照一下 robbin 的原文：
利用 erlang 的分布式能力，在两个 couchDb 或多个 couchDb 之间建立 replication ，通过这种方式解偶目前对于服务器端 db 的“单点”性要求（如，我有 n 个 db ，在任何一个上做操作，数据都会自动同步到其他的 db 上去，此乃 couch 这个缩写的要义）。
从上下文上看，我理解 robbin 意思的重点是“在这些应用场合”，说的是“实现某类业务，若采用 db 很麻烦，而用 docdb 会很简单，同时性能也比 db 要好”，而不是“ couchDb vs bdb/memcache 的性能比较”。
“性能更好”这种结论只能通过严格公正的实测来得出，作为 Erlang 的粉丝，虽说我也乐于见到 Erlang 的项目比其他技术实现具有更好的性能，但咱们还是要讲实验精神，拿数据说话，不能一看到 Erlang 的项目就认为其性能一定会好(实际上，我自己拿 Erlang 做的实验项目，性能就糟糕得很)。既然目前没有看到任何一方公布这样的测试结果，那么，对于“性能更好”这种问题，也就没有办法得出结论。
这是目前的 n 种 docdb 中为 couchDb 所独有的特性，这也是它给 web app 的开发模式带来的具有革命性意义的关键之所在。这个地方讲的是“开发效率”“开发模型”“开发语言”和“开发人员”。从某种意义上说，这是 killer 特性。这就好比，RoR 做的网站，若不小心优化很容易会有性能问题，但其具有 killer 特性的“高开发效率”，使得相比之下“明显较低的运行性能”也不能妨碍 n 多项目对其趋之若骛。
如果只是replication机制，基本上成型的db都有，连嵌入式的bdb都有，如果只是个大hash，以我对erlang的了解，似乎想不出优势会在什么地方。
搞大web的，看到性能两个字就两眼冒光，有点神经过敏。
关于 CouchDB 的最新消息是——作者本人已获得 IBM 的资助（用来专做 CouchDB 项目），而且有可能会成为 Apache 的正式项目。
请看这里。
这样的《如来神掌》可以放到Internet上跑吗?
javascript对客户是完全暴露的
匿名的客户可以知道口令,随意修改CouchDB 中保存的数据
＠YIN，不会存在你所担心的问题。验证／权限，这些东西在 HTTP 中就已经被支持了，RESTFUL 的应用直接拿这些机制来用就是了，至于这个应用是用Javascript写的还是用C写的，有那么大的差别么？
@jackyz,比如我们用couchDB 和Javascript写一个在线购书的网站的应用,
Javascript怎么连接couchDB,怎么完成验证／权限?
有什么连接密码用户看不到?
怎么保证用户不可以修改couchDB的其他记录?
就像我们在一个Powerbuild+sqlserver做的C/S系统一样,放在内网当然没问题,可以开源了,放在Internet上能跑吗?
那用户就都可以直接连接sqlserver,想做什么就做什么了!
B/S系统中用户只是提交表单而已,不能直接连接数据库,从而解决了这个问题.
couchDB 和Javascript的《如来神掌》相当于
Powerbuild+sqlserver做的C/S系统,放在Internet上能跑,还是开源了的,能安全吗?
不是Javascript写的还是用C写的问题
关键是你必须把操作数据库的代码放在server上
你认为呢?
比如你的线购书的网站
正常时数据库要记录
购买表:某用户,某书,1本
收款表:某用户,某书,10元
你javascript里的代码能够防止用户记录成
购买表:某用户,某书,100本
收款表:某用户,某书,10元
吗?
别的地方没代码了啊.
是每个购书者都在数据库中对应一个数据库用户吗?
显然,这是不可能的,internet上的用户太多了.
整个应用对应一个数据库用户,
而且用户名和密码还要写在avascript里,
那我想做什么就做什么了!
怎么解决呢?
＠YIN，没有深入研究过CouchDB的开发细节，你所说的安全问题，我还不知道其解决方案是什么。
我上一个回复的意思是：Http协议本身就已经定义了Auth机制，RESTful应用的安全可以从这一点来着眼。
既然RESTful是基于URL来定义资源的，因而，也就可以很方便的在URL的基础上来对于资源的访问进行控制（除了简单的ACL，还可以据此定义更复杂的RBAC）。
具体到CouchDB来开发应用，如果期望这个任务能在Browser端用纯JavaScript得到完成，可能并不是很现实。不过，比如说，在服务端给URL增加几个filter也不会是很复杂的事情。（比如，可以对URL“/cart/$NAME/*”定义一个限制“$AUTH_USER=$NAME”，而除了filter，没准还会有更好的方式。）
因为有了这个filter在服务端，严格意义上讲，也就不能再继续宣称整个应用是纯客户端JavaScript完成的《如来神掌》，这个说法是对的。但我想这个更严格的定义应该不是我们在讨论开发效率时所用的Context。因为，一方面这个访问控制层可以是高度可配的独立控件（就好比Apache的某个模块）；另一方面，“在关键的业务环节，不能信任客户端的提交，必须进行服务端的校验”这也是Web（or电子商务）编程的基本原则之一，任何的架构模式下恐怕也都是必须的。
很好玩的东东啊，不过上面各位好像有点各说各话的意思！
@YIN，似乎你所说的 Javascript 是指在浏览器中执行的吧？
Javascript 只是一种语言，可以做为浏览器的脚本，自然也可以做为 CouchDB 的脚本，CouchDB 集成了 SpiderMonkey 引擎，所以，就像你说的，操作数据库的代码确实是在 Server 上啊。