On 04/19/2010 10:22 AM, Adam Kocoloski wrote:
On Apr 19, 2010, at 10:10 AM, Eric Casteleijn wrote:
I still wonder in that case if there is something you can do to shrink the stored views somewhat: gwibber had a number of views that emitted the whole document, but those documents (typically representing a twitter or identi.ca message) weren't very large in themselves. My database, after compaction was something between 70 and 80 MB, whereas the indexes took over a GB. Since gwibber+desktopcouch run on the desktop, where only one client typically talks to couch, I still think we made the right decision to sacrifice speed for diskspace. On a server, both are important though, considering we host multiple couchdbs per user. Luckily we don't compute the views for the gwibber dbs server side, but I'm sure it's something we'll run into again elsewhere. >
Were the view indices also compacted? If so, that's very surprising to me. I should double-check our numbers, but I seem to remember the compacted view indices for our case (which had similarly-sized documents) being comparable in size to the DBs.
I believe so, unless compacting view indices is a separate process that is not triggered by compacting a database?
There are a few things we can do to decrease the size of uncompacted view indices. Chief among those is to put a lower bound on the size of a view index write, as reported by Henrik Jensen last month (COUCHDB-700). Cheers, Adam
Cool, I will look that up! -- eric casteleijn https://code.launchpad.net/~thisfred Canonical Ltd.
