Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.194 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: associating UUIDs to DBs
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: <ec7a93a1002041405q74608f77s4b566a166c243f28@mail.gmail.com>
Date: Thu, 4 Feb 2010 17:12:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DB10989-7DA6-4007-BBF1-FA5BF9A63898@apache.org>
References: <cadf1c691002011058r1cf1fbfbk45a41db9ea3932f7@mail.gmail.com>
 <ec7a93a1002021125j11a87224h4b98ac64066cc7d9@mail.gmail.com>
 <e282921e1002021139u660e81e2n77ee23b897aaad90@mail.gmail.com>
 <ec7a93a1002021148u20751c9chd1aed06e95c05257@mail.gmail.com>
 <C96C3CAC-77BB-4CCA-A3C2-BD734419B176@apache.org>
 <46aeb24f1002021341h3a3e6a62l9ab92274646f2c74@mail.gmail.com>
 <20100203095327.GA8099@uk.tiscali.com>
 <7CBFD4B9-23DB-4626-9FC6-81095E1A4161@apache.org>
 <e2111bbb1002040744y6eb3ce38q1bc9b3dfaae870f9@mail.gmail.com>
 <2EBB675B-A3C2-494A-B3FA-19D089D38268@apache.org>
 <ec7a93a1002041405q74608f77s4b566a166c243f28@mail.gmail.com>
To: dev@couchdb.apache.org

On Feb 4, 2010, at 5:05 PM, Randall Leeds wrote:

> On Thu, Feb 4, 2010 at 08:17, Adam Kocoloski <kocolosk@apache.org> =
wrote:
>>=20
>> If we went ahead and implemented this I think the UUID becomes =
superfluous from the replicator's perspective.  You wouldn't want to =
restrict this Merkle tree check to UUID-matched DBs, as it would be =
useful for reducing entropy in a sharded database cluster that stores =
multiple copies of each document in different database shards.  In fact, =
IIRC that was a Dynamo feature in the original Amazon paper.
>=20
> I mostly follow and I think I agree.
> Can you clarify "as it would be useful for reducing entropy..."?
>=20
> Randall

Sure, that was too terse on my part.  I'm referring to the case where =
you're promising to write N copies of a document in your cluster, but =
for whatever reason you only succeed W<N times.  Hence "entropy" -- the =
N shards start diverging from one another after transient failures.

You want those missing writes to eventually propagate to the N-W shards =
that didn't get them.  CouchDB's _changes replication works for this =
purpose, but it's relatively resource-intensive because it checks for =
the existence of every update on the target.  I suspect that comparing =
Merkle trees may be a more efficient way to figure out what to replicate =
in this special case where the two DBs are always supposed to be =
identical.  Cheers,

Adam