you can just rsync or copy the files while CouchDB is running. Thanks to CouchDB’s append-only file structure this is safe.

Yes, it’s so easy. Operational cost optimization.

Original title and link: CouchDB Incremental Backups (NoSQL databases © myNoSQL)

via: http://comments.gmane.org/gmane.comp.db.couchdb.user/11410

CouchDB group_level applied:

CouchDB supports something called group_level in the view queries. On pcapr, we never really had the need to use this feature though we have over 52 different views. But in a recent internal project, we had the need to display folders in the application that can be expanded and collapsed. Each document in CouchDB represents a file of sorts and contains the relative path name. One of the views in the app is a classic folder view that can be expanded recursively. Obviously, from a scaling perspective, we don’t want to load all this data up front and that’s exactly where the group_level comes in. This was my first time playing with this capability and I have to say, once you get grok this, it’s totally cool.

You can read more about CouchDB group_level ☞ here and ☞ here.

Original title and link: CouchDB group_level for hierarchical data (NoSQL databases © myNoSQL)

via: http://labs.mudynamics.com/2010/10/02/using-couchdb-group_level-for-hierarchical-data/

Via ☞ Mikeal Rogers:

Currently (CouchDB 0.11.0) there are three built-in reduce functions. Built-in reduce functions are performed right inside CouchDB implemented in Erlang. In most cases it is very fast because they are way more efficient.

J. Chris Anderson explains why built-in reduce functions are faster:

The deal is that map function (and intermediate reduce function) output is cached in the view index (as it is generated). So in those cases the function overhead is not an issue.

But in the case of reduce, for any query that has parameters (even a startkey and endkey) the JavaScript function will be executed once (and fed the intermediate cached results), to give the accurate answer to the query. Once is fine and fast enough, but in the case of group=true or group_level=N queries, the JavaScript function is executed once per row of output so that starts to slow things down (in a linear way, related to the # of group rows, not the # of map rows, so it’s still “scalable”)

Using the builtin reduces avoids the interprocess communication overhead of calling the JavaScript function once per row, in a situation where the output cannot be cached.

In the normal operations, the JavaScript is batched and cached, so the effects of the slowness are mitigated.

via: http://wiki.apache.org/couchdb/Built-In_Reduce_Functions

Very interesting idea of having FS-level compression kicking in automatically on CouchDB compressions from Victor Igumnov:

CouchDB was made for next generation filesystems such as ZFS and BTRFS. First off, unlike PostgreSQL or MySQL, CouchDB can be snapshot while in production without any flushing or locking trickery since it uses an append only B-Tree storage approach. That alone makes it a compelling database choice on ZFS/BTRFS.

Second, CouchDB works hand-in-hand with ZFS’s block level compression. ZFS can compress blocks of data as they are being written out to the disk. However, it only does it for new blocks and not retroactively. Now, the awesome part, CouchDB on compaction writes out a brand new database file which can utilize the new gzip compression settings on ZFS. This means you can try out different gzip compression settings just by compacting your CouchDB.

via: http://letsgetdugg.com/2010/06/25/couchdb-on-zfs/

Just because CouchDB uses Multi Versioning Concurrency Control (or MVCC^[1]) doesn’t mean that you’ll also get document versioning support by default. So, how would you go if you need document versioning in CouchDB?

This article takes a look at 4 different approaches and details the first one as it looks to be both simple, scalable and supported by CouchDB replication:

1. storing as a binary attachment the previous version
2. append old versions to an array embedded in the current document
3. keep each version as a separate document
4. skip compaction

How does storing previous document version as a binary attachment to the new version work?

[…] when the document is loaded from the CouchDB server, the string representation is saved before being parsed into JSON. Later, when the document is saved, the string representation is attached as a new binary attachment, with the corresponding rev as it’s name, and a content type of application/json. This way any CouchDB library can just open the stored rev, and see it as a normal document.

This means that each time the document is updated, the client will also store the previous version as an attachment to the latest version. At any time, a user can load any of the old versions.

via: http://blog.couch.io/post/632718824/simple-document-versioning-with-couchdb

The very basics of CouchDB

via: http://www.andyjarrett.co.uk/blog/index.cfm/2010/3/29/CouchDB-quick-refstarting-guide

CouchDB view collation is great and only has one real drawback that has caused me any real pain – the inability to handle queries that need to be parameterised by more than one dimension.

Do you know any solutions for this scenario?

via: http://jamietalbot.com/2010/03/24/using-multiple-start-and-end-keys-for-couchdb-views/

For the last couple of weeks, we’ve run a series of CouchDB Tips and I think that this one would be a nice addition to the list.

Starting with its version 0.10, CouchDB offers the possibility to perform server-side processing of incoming documents before they are committed. This feature is available through document update handlers defined in a design doc. You can find more details and a sample application of this feature on the linked page.

via: http://wiki.apache.org/couchdb/How_to_intercept_document_updates_and_perform_additional_server-side_processing

Just another trick for your CouchDB toolbox:

List functions are a mechanism for iterating over rows in a view to produce output. CouchDB list functions are typically used to generate alternate formats for output (Atom, XML, HTML, etc.). I still want to generate JSON for consumption by my Sinatra application. Hopefully, that will not prove difficult.

Other CouchDB tips&tricks

• Paginating with CouchDB
• Access CouchDB document revisions with RelaxDB
• Generic CouchDB _changes consumer using node.js
• A Stub Ruby Library for CouchDB

via: http://japhr.blogspot.com/2010/02/collating-not-reducing-with-couchdb.html