On 25/02/2009, at 8:52 AM, Brian Candler wrote:
On Tue, Feb 24, 2009 at 01:48:56PM +0100, Jan Lehnardt wrote:
However, you must then be prepared for your database to be a single
file
which grows without bounds. If CouchDB wants to support this
model, it
would
be helpful if the data were stored in chunks which can be backed up
separately.
rsync? :)
Doesn't work especially well on huge files.
What about this incremental backup strategy:
1. Split off the MVCC header
2. Compare the previous and current file lengths and split of the new
tail
3. Backup the header and the tail
I'm not sure about 'kitchen sink', but I've seen desires expressed
for more
pluggability; perhaps JSON could be a pluggable layer sitting on top
of a
raw document store?
I've been thinking about the layering in CouchDB along these lines:
MVCC Store
Replication | Map/Reduce
in order to allow different replication strategies. I think of CouchDB
as a collection of features that can themselves be plugged together to
build systems with different semantics.
Rrather than making Couch more pluggable, we could make it more of a
construction kit. There's already a flavour of this when you look at
the .ini file that builds up a Couch server from different endpoints
and daemons.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The truth does not change according to our ability to stomach it.
-- Flannery O'Connor
