Heya Ban,
On Nov 9, 2008, at 02:31, Ben Browning wrote:
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?
Number of documents in your database. CouchDB traverses a database
('s b-tree) and reads the latest revision of each doc into a new
database.
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?
Yes, bulk inserts are written in a more compact manner that requires
less
compaction. Replication uses bulk inserts.
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)?
Replication to a database is a 'write' as far as the database is
concerned.
So lots of replication activity might cause compaction to timeout. Is
that
what you were asking? Having replication stop for a second or so usually
is well enough time to have compaction catch-up and finish (your mileage
may vary).
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.
Cool, feel free to send any follow-up questions and please do report any
issues :-)
Cheers
Jan
--
