couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Why are all Views in a single Index" by BenjaminYoung
Date Mon, 13 Feb 2012 20:48:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Why are all Views in a single Index" page has been changed by BenjaminYoung:
http://wiki.apache.org/couchdb/Why%20are%20all%20Views%20in%20a%20single%20Index?action=diff&rev1=1&rev2=2

Comment:
some general cleanup and specificity added for clarity

  = Why are all Views in a single Index =
  by [[http://fdmanana.wordpress.com/|Filipe Manana]]
  
- Each view basically corresponds to 1 btree. All live in the same file. Other than saving
the number of file descriptors and possibly, some OS page caching benefits, and simpler code,
I don't think there's more benefits.
+ Each view basically corresponds to one btree. All views live in the same index file. Other
than saving the number of file descriptors and possibly, some OS page caching benefits, and
simpler code, I don't think there's more benefits.
  
- Now the real benefit comes when in the same ddoc you have 2 (or more) views with the same
map function. For example:
+ However, the most significant benefit comes when you have two (or more) views with the same
map function in a single design document.
+ 
+ For example:
  
  {{{
  view1: {
@@ -29, +31 @@

    "reduce": "_sum"
  }
  }}}
- Here view1 and view2 have exactly the same map function. Would they be in different ddocs,
we would have 2 btrees (in 2 different files) for exactly the same data. Now, if they're in
the ddoc, we use 1 btree only but with 2 different reduce values - this saves disk space and
update time (1 only update 1 btree instead of 2) - of course, this is easy only because we
use 1 single file for a ddoc with multiple views.
+ Here view1 and view2 have exactly the same map function. If they were in different design
documents, there would be two b-trees (in two different index files) for exactly the same
data. Now, if they are in a single design document, we use one b-tree only, but we save disk
space and update time by only updating one btree instead of two. Of course, this is easy only
because we use one single index file for a design document with multiple views.
  

Mime
View raw message