CouchDB能从使用BERT而不是JSON中获得显著的好处吗？

我很欣赏CouchDB尝试在它所做的一切中使用通用web格式：RESTFUL HTTP方法在每次交互中，JSON对象，javascript代码来定制数据库和文档

CouchDB的规模似乎相当大，但提出请求的个人成本通常会让“关系型”的人害怕

许多小型企业应用程序应该只处理一台机器，仅此而已。在这种情况下，可伸缩性讨论并没有说太多，我们需要每个请求都有更高的性能，否则人们不会使用它

BERT（二进制ERlang术语）是一种比JSON更快、更轻的格式，它是编写CouchDB的语言ERlang的本机格式。使用BERT文档而不是JSON文档，我们能从中受益吗？

我说的不仅仅是在视图中检索，而是CouchDB所做的一切，包括同步。因此，使用Erlang函数而不是javascript函数

---

这将修改一些原始的CouchDB原则，因为现在它非常面向web。考虑到我认为很少有人会公开他们的数据库API，并且通常用户通过应用程序访问数据库API的数据，因此最好能够配置CouchDB以加快工作速度。HTTP+JSON调用仍然可以由CouchDB处理，因为在这些情况下解析会带来额外的成本

你可以看看。它为CouchDB提供了一个本机Erlang接口。将其与CouchDB已经支持的Erlang视图相结合，您可以拥有一种全Erlang CouchDB（一些外部库，如ICU，仍然需要安装）。

CouchDB需要最大的数据可移植性。您无法在浏览器中解析BERT，这意味着它无法移植到世界上最大的平台上，因此对于基本CouchDB来说，这是一种非入门级功能。尽管如上所述，BERT在气垫船中可能有一席之地。

我认为首先应该衡量JSON处理带来的开销：JSON处理可能非常有效。例如，JSON是Java平台上最快的无模式数据格式（协议缓冲区需要严格的模式，avro也是如此；kryo是Java序列化程序）；我假设在其他平台上也可以这样做（使用erlang；对于通过本机支持的浏览器）

---

所以，“如果它没有坏，就不要修理它”。当正确实现时，JSON非常快；如果考虑到空间的使用，它会像任何文本格式一样进行压缩。

似乎是社区wiki的一个很好的选择。但是在“传统设置”中，浏览器和数据库无法通信，那么为什么浏览器会将需求放在DB后端呢？浏览器需要与数据库直接通信的只是CouchApps'n'之类的东西，但这是一个不同的界面。。。我相信App-to-DB和DB-to-DB（复制）通信不应该受此影响。能够直接对数据库进行和xhr调用，并且在不编写更多后端代码的情况下获取数据，这是一种令人难以置信的解放。还有其他好处，比如免费缓存，因为ETag会在文档和查询发生变化时更新。这可能是文化原因，但我不喜欢让用户公开访问我的数据库。这很可能会给他们提供不应该查看的信息，或者最糟糕的是，让他们能够访问不应该修改的更改数据。如果这种访问控制在CouchDB中非常清晰且易于维护，那么这可能没问题。但是关于与浏览器的通信，如果这是人们想要的，我认为在直接与客户端web app交谈时，每个请求有多一点时间从BERT解析为JSON，反之亦然，没有问题。由于webapps非常习惯于在服务器端腾出一些时间来做ORM工作，因此给服务器应用程序更多的功能并不坏，跳过http和json（但保持RESTful思维），虽然客户端应用程序因为处理JSON格式而变得有些懒散。通常情况下，我同意用户对DB访问的关注，但CouchDB trunk包含了一些惊人的新用户/身份验证功能，可以处理我在编写Web应用程序时通常需要的ACL。