incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <nate-li...@calftrail.com>
Subject Re: Database size seems off even after compaction runs.
Date Mon, 26 Dec 2011 18:10:54 GMT
On Dec 23, 2011, at 2:56 PM, Chris Stockton wrote:
> Hello,
> 
> On Fri, Dec 23, 2011 at 5:48 AM, CGS <cgsmcmlxxv@gmail.com> wrote:
>> Hi,
>> 
>> Sorry to interfere with such a question, but why don't you work with a
>> buffer database? I mean, make a replica to another database which filters
>> out the deleted documents. In such way you can clean all your databases and
>> you use temporary some extra-space (only during the "cleaning" process).
>> Another idea would be to use two databases: one active and one inactive at
>> the given time. That means, you move the data from one to the other,
>> filtering out the deleted documents, and when it's over, you switch to the
>> newly constructed database, while the other gets emptied (deleted and
>> re-created). Just my 2c opinions.
>> 
>> CGS
>> 
> 
> Thanks everyone for the various feedback. Now the information I have
> gathered is the disk utilization we are seeing is simply from the
> deleted documents.
> 
> The question I have yet to see answered (perhaps because it simply
> isn't possible) is how to reclaim this space?


One potential option, not sure if it's ideal for your use case, could be using the purge command
on the deleted documents, followed by a compaction.

What this does is *completely forget* the document in the btree (no "tombstones"):

POST /db/_purge -d '{"id1":["rev1"], "id2":["rev2"]}'

This will thwart replication, i.e. this deletion will not propagate and the document may get
pushed back into existence if another database has it.

hth,
-natevw
Mime
View raw message