From dev-return-23515-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 25 08:18:14 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 78F33D6DA for ; Thu, 25 Oct 2012 08:18:14 +0000 (UTC) Received: (qmail 46375 invoked by uid 500); 25 Oct 2012 08:18:13 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 46307 invoked by uid 500); 25 Oct 2012 08:18:12 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 46289 invoked by uid 99); 25 Oct 2012 08:18:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Oct 2012 08:18:12 +0000 Date: Thu, 25 Oct 2012 08:18:12 +0000 (UTC) From: "Dave Cottlehuber (JIRA)" To: dev@couchdb.apache.org Message-ID: <1956177243.26568.1351153092433.JavaMail.jiratomcat@arcas> In-Reply-To: <532970440.26494.1351151892253.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (COUCHDB-1576) Allow deletions to expire after set time MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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