couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Fail on a simple case on replication
Date Tue, 24 Feb 2009 22:49:30 GMT

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  
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

View raw message