[
https://issues.apache.org/jira/browse/COUCHDB-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483970#comment-13483970
]
Dave Cottlehuber commented on COUCHDB-1576:
-------------------------------------------
Thanks Michel for reporting this. This is a consequence of using MVCC to enable
straightforward replication and conflict handling API.
Are you aware of _revs_limit, a per-DB setting? It's not time-based but during
compaction and replication this is taken into account:
http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options
http://wiki.apache.org/couchdb/Compaction/
Compaction is the way to recover that space, and for very active DBs the
typical approach is to use a transactional DB and:
- either rotate them on a regular basis
- or aggregate to a separate metrics DB and re-create a fresh / empty DB
regularly.
Is there an actual issue or barrier you're running into that won't be addressed
by either compaction, or the transactional DB pattern?
> Allow deletions to expire after set time
> ----------------------------------------
>
> Key: COUCHDB-1576
> URL: https://issues.apache.org/jira/browse/COUCHDB-1576
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Affects Versions: 1.2
> Reporter: Michel Meyers
>
> Currently, CouchDB keeps all deletions forever. On a very active database
> this can lead to the number of deletions actually exceeding the number of
> active documents.
> Lotus Domino solves this by having a cut-off date after which deletion stubs
> are purged from a replica. It would be great to have a similar functionality
> in CouchDB, e.g. have a setting that determines how long deletion stubs are
> kept and then purges them from the local copy. Whether this setting resides
> in the DB design, and thus replicates everywhere, or possibly an INI setting
> for the local CouchDB instance is still to be determined.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
