Erlang Views in Couch DB

问题:

Its possible to write views in Erlang to query Couch DB. The views written in Erlang are said to be faster than those written in JavaScript. This Article shows this possibility. However, it explains that we can type an Erlang fun as a temporary view directly in the futon: CouchDB Web interface

Question 1: Where can i find examples of Couch DB views written in Erlang, or atleast a tutorial of whats required in doing so ( In your answer, i would appreciate an example of a view written in Erlang which shows all basic techniques for map and reduce as well as selecting and filtering from documents in Couch ) ?

Question 2: Also, the Erlang Couch DB client, called Hover craft is said to be very much faster because it avoids HTTP overhead as well as JSON conversion overheads. How does it avoid HTTP overheads ?

回答1:

Answer 1: Here is the link to "tutorial" how to set it up http://wiki.apache.org/couchdb/EnableErlangViews Most important thing is [native_query_servers] erlang = {couch_native_process, start_link, []} in local.ini file where you set it to use this query server.

Answer 2: It avoids http overhead because regular Query Server is just a standalone process that gets data in json and process it. So Couchdb has to serialize it to json and then deserialize answer from process by using embedded erlang views you simply skip this phase. And this is the main reason behind "faster". I don't know if he is storing internally compiled views but anyway it is much faster.

回答2:

For the second question, my answer would be that hovercraft is faster because the call to couchdb never leaves the VM. To use hovercraft you load the beams in the same node as the couchdb runs in and hovercraft will make erlang calls directly to couchdb and will not leave the node.

This is of course much faster than communicating over http especially when having to convert back and forth between json/eterms.

One drawback is though that couchdb doesn't have an erlang api hence hovercraft is forced to call non-api functions below the http-api.

On the question of erlang views, I can add some experience. I tried out the Erlang views some years ago and I was really impressed by the speedup I got compared to the javascript one. If I recall correctly it was in the order of 5x so I really recommend it. Also, debugging views got a bit easier