Writing and Querying MapReduce Views in CouchDB

Storage Considerations

The examples in this book involve using only a handful of views, each with a handful of rows. You will want to consider the storage implications of the views in you database as you will likely have more views, each with more rows. CouchDB views use extra disk space in exchange for additional performance and for concurrency purposes. Some benefits of this approach are that huge amounts of data can be accessed very quickly and that your data can always be read, even when your database is being written to, but you will want to carefully choose and design your views in order to preserve disk space.

Each view in your database is stored as its own B-tree index. CouchDB views can be written to without blocking read operations. Write operations are serialized, but concurrent read operations are allowed. CouchDB will provide a consistent view of the database to each and every read operation. This is achieved by only ever appending to the B-tree file on each update. The one exception to this append-only rule is the part of the file containing the B-tree root node, which is overwritten on each update. Existing parts of the file are never changed (except for the part containing the B-tree root node) and file pointers to an old B-tree root node will still provide a consistent, if possibly outdated, snapshot of the database. This append-only design can lead to large index files. See the CouchDB Wiki page on Compaction for information on how to compact and clean up views. ...