You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Vladimir Ralev <vl...@gmail.com> on 2014/01/20 17:29:56 UTC
Number of surviving revisions after compaction
Hello all
I was reading about _revs_limit
<http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options>
which
defaults to 1000 or so here
http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options
It seems to imply that those 1000 revisions will be preserved even after
compaction.Is this correct and does it mean that the database will be as
much as 1000x bigger than it needs to be after compaction.
I have a database that I want to perform maintenance on so i remove it from
traffic and want to reduce the number of revisions to 1 again safely. Is
there some shortcut to do that?
Re: Number of surviving revisions after compaction
Posted by Jens Alfke <je...@couchbase.com>.
On Jan 20, 2014, at 11:23 AM, Paul Davis <pa...@gmail.com> wrote:
> Thus your db won't be
> 1000x larger than it needs to be and setting _revs_limit lower won't
> save you that much on disk space.
IIRC, the overhead of keeping revision history is on the order of 50 bytes per revision (just the space for storing its _rev ID). If you have huge numbers of small documents, or if you continually create and delete lots of documents, this can add up; but it's not significant in most use cases.
—Jens
Re: Number of surviving revisions after compaction
Posted by Paul Davis <pa...@gmail.com>.
Slightly more precisely, _revs_limit affects the number of revisions
kept for each edit branch. While Adam's point about the replicator is
valid I don't think its quite the answer that Vladimir is looking for.
The compactor removes document bodies for each revision that is not a
leaf of the revision tree during compaction. Thus your db won't be
1000x larger than it needs to be and setting _revs_limit lower won't
save you that much on disk space.
On Mon, Jan 20, 2014 at 8:36 AM, Adam Kocoloski <ko...@apache.org> wrote:
> On Jan 20, 2014, at 11:29 AM, Vladimir Ralev <vl...@gmail.com> wrote:
>
>> Hello all
>>
>> I was reading about _revs_limit
>> <http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options>
>> which
>> defaults to 1000 or so here
>> http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options
>>
>> It seems to imply that those 1000 revisions will be preserved even after
>> compaction.Is this correct and does it mean that the database will be as
>> much as 1000x bigger than it needs to be after compaction.
>>
>> I have a database that I want to perform maintenance on so i remove it from
>> traffic and want to reduce the number of revisions to 1 again safely. Is
>> there some shortcut to do that?
>
> Hi, that setting controls the number of revisions about which the server keeps a record, not the number where the actual body of the rev is preserved. Compaction only ever preserves the last revision of each edit branch; this is not configurable. The _revs_limit setting impacts replication, e.g. if you make 1001 edits on a source server in between replications to a target the replicator will not be able to piece together edit 1 and edit 1002 and you'll end up with a spurious conflict on the target.
>
> Adam
Re: Number of surviving revisions after compaction
Posted by Adam Kocoloski <ko...@apache.org>.
On Jan 20, 2014, at 11:29 AM, Vladimir Ralev <vl...@gmail.com> wrote:
> Hello all
>
> I was reading about _revs_limit
> <http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options>
> which
> defaults to 1000 or so here
> http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options
>
> It seems to imply that those 1000 revisions will be preserved even after
> compaction.Is this correct and does it mean that the database will be as
> much as 1000x bigger than it needs to be after compaction.
>
> I have a database that I want to perform maintenance on so i remove it from
> traffic and want to reduce the number of revisions to 1 again safely. Is
> there some shortcut to do that?
Hi, that setting controls the number of revisions about which the server keeps a record, not the number where the actual body of the rev is preserved. Compaction only ever preserves the last revision of each edit branch; this is not configurable. The _revs_limit setting impacts replication, e.g. if you make 1001 edits on a source server in between replications to a target the replicator will not be able to piece together edit 1 and edit 1002 and you'll end up with a spurious conflict on the target.
Adam