Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ben324@gmail.com designates
 209.85.128.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type
         :content-transfer-encoding:content-disposition;
        b=gDZjWVauU7/D38TP/lcIEyTCVZ8T1m9B60ljOxW4a5JqKiWyIDV3Ak6LSqe71uRnA8
         lr0UhqcdAF7qr90v6vkI/usmw2Qr6JlXixqXVo4Z1Ye7UqsZnHo53CFc+kAtE5dLXq29
         FcKW9hV+FXP4bVD/xMlxxy3DG7+mSG2PE++yk=
Message-ID: <d72c12bb0811081731o1bb8f493xccaca173a602d8ff@mail.gmail.com>
Date: Sat, 8 Nov 2008 20:31:00 -0500
From: "Ben Browning" <ben324@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: What Factors Influence Compaction Time?
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

How does compaction time change as my database grows? Is it a function
of database size, number of changes since the last compaction, or
something else? Also, if I have many write instances all replicating
their changes to a master read instance, how will this impact
compaction? Does replication effectively perform bulk updates to
reduce the need for compaction on the read node? If not, does the same
warning about compacting a database under high write load also apply
to a database under high replication load (with changes being
replicated to this database)?

I'm designing a system that, other than being write-heavy, is a great
fit for CouchDB. I'm just trying to figure out how to architect things
to work best with lots of writes.

Thanks,

Ben