CouchDB 能否从使用 BERT 而不是 JSON 中获益匪浅？
我很欣赏 CouchDB 在它所做的一切中尝试使用通用 Web 格式：每次交互中的 RESTFUL HTTP 方法、JSON 对象、javascript 代码定制数据库和文档。
CouchDB 似乎可以很好地扩展，但是提出请求的个人成本通常会让“关系型”人员感到害怕。
许多小型企业应用程序应该只处理一台机器，仅此而已。在这种情况下，可扩展性讨论并没有说太多，我们需要每个请求更高的性能，否则人们不会使用它。
BERT（二进制 ERlang 术语 http://bert-rpc.org/ ） 已被证明是比 JSON 更快、更轻的格式它是 Erlang 的本机语言，CouchDB 是用 Erlang 编写的。 使用 BERT 文档而不是 JSON 文档，我们可以从中受益吗？
我并不是说仅仅为了在视图中检索，而是为了 CouchDB 所做的一切，包括同步。因此，使用 Erlang 函数而不是 javascript 函数。
这将修改一些原始的 CouchDB 原则，因为今天它非常面向 Web。考虑到我想象很少有人会公开他们的数据库 API，并且通常用户通过应用程序访问其数据，因此能够配置 CouchDB 以提高工作速度将是一件好事。 HTTP+JSON 调用仍然可以由 CouchDB 处理，考虑到这些情况下由于解析而产生的额外成本。
I appreciate a lot CouchDB attempt to use universal web formats in everything it does: RESTFUL HTTP methods in every interaction, JSON objects, javascript code to customize database and documents.
CouchDB seems to scale pretty well, but the individual cost to make a request usually makes 'relational' people afraid of.
Many small business applications should deal with only one machine and that's all. In this case the scalability talk doesn't say too much, we need more performance per request, or people will not use it.
BERT (Binary ERlang Term http://bert-rpc.org/ ) has proven to be a faster and lighter format than JSON and it is native for Erlang, the language in which CouchDB is written. Could we benefit from that, using BERT documents instead of JSON ones?
I'm not saying just for retrieving in views, but for everything CouchDB does, including syncing. And, as a consequence of it, use Erlang functions instead of javascript ones.
This would modify some original CouchDB principles, because today it is very web oriented. Considering I imagine few people would make their database API public and usually its data is accessed by the users through an application, it would be a good deal to have the ability to configure CouchDB for working faster. HTTP+JSON calls could still be handled by CouchDB, considering an extra cost in these cases because of parsing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你可以看看hovercraft。它为 CouchDB 提供了本机 Erlang 接口。将此与 CouchDB 已经支持的 Erlang 视图相结合，您可以拥有一种全 Erlang CouchDB（仍然需要安装一些外部库，例如 ICU）。
You can have a look at hovercraft. It provides a native Erlang interface to CouchDB. Combining this with Erlang views, which CouchDB already supports, you can have an sort-of all-Erlang CouchDB (some external libraries, such as ICU, will still need to be installed).
CouchDB 想要最大程度的数据可移植性。您无法在浏览器中解析 BERT，这意味着它无法移植到世界上最大的平台，因此这对于基础 CouchDB 来说是不可能的。尽管如上所述，BERT 在气垫船中可能有一席之地。
CouchDB wants maximum data portability. You can't parse BERT in the browser which means it's not portable to the largest platform in the world so that's kind of a non-starter for base CouchDB. Although there might be a place for BERT in hovercraft as mentioned above.
我认为首先最好测量一下 JSON 处理带来的开销：JSON 处理非常高效。例如，这些结果表明 JSON 是最快的无架构数据格式在 Java 平台上（协议缓冲区需要严格的架构，avro 也是如此；kryo 是 java 序列化器）；我认为在其他平台上也可以完成同样的操作（使用 erlang；对于通过本机支持的浏览器）。
所以，“如果它没有坏，就不要修理它”。如果正确实现，JSON 非常快；如果考虑空间使用，它可以像任何文本格式一样压缩得很好。
I think it would be first good to measure how much of overhead is due to JSON processing: JSON handling can be very efficient. For example these results suggest that JSON is the fastest schema-less data format on Java platform (protocol buffer requires strict schema, ditto for avro; kryo is java serializer); and I would assume that same could be done on other platforms too (with erlang; for browsers via native support).
So, "if it ain't broke, don't fix it". JSON is very fast, when properly implemented; and if space usage is concern, it compresses well just like any textual formats.