我很欣赏CouchDB尝试在其所做的一切中使用通用网络格式： RESTFUL HTTP方法在每次互动中， JSON 对象， javascript 自定义数据库和文档的代码。
CouchDB似乎规模相当不错，但提出请求的个人成本通常会让“关系型”人员感到害怕。
许多小型企业应用程序应该只处理一台机器，而这就是全部。在这种情况下，可伸缩性谈话并没有说太多，我们需要每个请求更多的性能，否则人们将不会使用它。
BERT （二进制ERlang术语http://bert-rpc.org/）has proven是一种比JSON更快更轻的格式，它是用于编写CouchDB的语言Erlang的原生语言。我们可以从中受益吗，使用BERT文档而不是JSON文档？
我不仅仅是为了在视图中进行检索，而是为了CouchDB所做的一切，包括同步。并且，由于它，使用Erlang函数而不是javascript 。
这将修改一些原始的CouchDB原则，因为今天它非常面向Web。考虑到我认为很少有人会公开他们的数据库API，并且通常用户通过应用程序访问其数据，因此能够更快地配置CouchDB是一个很好的选择。由于解析，考虑到这些情况下的额外成本，CouchDB仍然可以处理HTTP + JSON调用。
答案 0 :(得分：4)
您可以查看hovercraft。它为CouchDB提供了一个本机Erlang接口。将此与CouchDB已经支持的Erlang视图相结合，您可以拥有一种全Erlang CouchDB（某些外部库，例如ICU，仍然需要安装）。
答案 1 :(得分：1)
CouchDB希望获得最大的数据可移植性。你无法在浏览器中解析BERT，这意味着它无法移植到世界上最大的平台上，所以这对于基础CouchDB来说是一种非首发。虽然如上所述，在气垫船中可能存在BERT的位置。
答案 2 :(得分：0)
我认为首先衡量JSON处理的开销是多少：JSON处理非常有效。例如these results表明JSON是Java平台上最快的无模式数据格式（协议缓冲区需要严格的模式，同样适用于avro; kryo是java序列化程序）;我认为同样可以在其他平台上完成（使用erlang;对于通过原生支持的浏览器）。
所以，“如果没有破坏，就不要修理它”。正确实施JSON非常快;如果空间使用受到关注，它就会像任何文本格式一样压缩。