Comments on: Writing binary data to CouchDB http://blog.loftninjas.org/2009/02/27/writing-binary-data-to-couchdb/ Sat, 21 Jan 2012 06:46:54 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jan L http://blog.loftninjas.org/2009/02/27/writing-binary-data-to-couchdb/comment-page-1/#comment-2053 Jan L Sat, 28 Feb 2009 08:58:23 +0000 http://labs.widemile.com/?p=19#comment-2053 Hi Bryan, what Chris said, except that if you create an attachment to a nonexisting doc, the doc is created implicitly. Cheers Jan -- Hi Bryan,

what Chris said, except that if you create an attachment to a nonexisting doc, the doc is created implicitly.

Cheers
Jan
–

]]> By: J Chris A http://blog.loftninjas.org/2009/02/27/writing-binary-data-to-couchdb/comment-page-1/#comment-2052 J Chris A Sat, 28 Feb 2009 03:00:47 +0000 http://labs.widemile.com/?p=19#comment-2052 CouchDB has had binary attachment support since shortly after the 0.8.1 release. Binary attachments are not sent to the view server, and take advantage of the fact that they are not JSON documents by being streamed to disk in parallel. In tests using the direct Erlang API with one 250KB attachment per document I was able to store roughly 20MB/sec of data to disk. This is about 80% of my disk's raw speed, and I've still got tuning to do. I imagine it would not be much slower with HTTP PUTs but there's an API design challenge about how to do that without having to make 2 requests per attachment (one to make the doc and one to add the attachment...). My benchmark saved attachments 1000 at a time, which is also harder to do with the HTTP API. Nevertheless, the underlying storage engine is MUCH faster than what you are seeing in 0.8.1. CouchDB has had binary attachment support since shortly after the 0.8.1 release. Binary attachments are not sent to the view server, and take advantage of the fact that they are not JSON documents by being streamed to disk in parallel. In tests using the direct Erlang API with one 250KB attachment per document I was able to store roughly 20MB/sec of data to disk. This is about 80% of my disk’s raw speed, and I’ve still got tuning to do. I imagine it would not be much slower with HTTP PUTs but there’s an API design challenge about how to do that without having to make 2 requests per attachment (one to make the doc and one to add the attachment…). My benchmark saved attachments 1000 at a time, which is also harder to do with the HTTP API. Nevertheless, the underlying storage engine is MUCH faster than what you are seeing in 0.8.1.

]]>