Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of david.vancouvering@gmail.com
 designates 209.85.198.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=references:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date:cc;
        b=AeX6jbmdStt/TWDmsH0h5esnTM7LdttEFSrF/mQU6qzm4o3cyZgM07E77mp1S42rDn
         Tq6vGxu4MabChAb/vPSKrEXwQZadVqMjaroQI8uFHBaro99dJP4DHbRVD7sY2FK07JFQ
         u0hUMpZ00H7LSNWTZogqk0g0OSPN5Ca1iyxr4=
References: <56a83cd00902260948x15ce887u4916cedd54959c6@mail.gmail.com>
 <7898CB93-1504-40B6-8EB8-C4C816189EB8@apache.org>
 <d72c12bb0902261404r7d77eaabj9e09b7ba0356038d@mail.gmail.com>
 <73AF9D27-6895-4E0D-96E0-335C02B94892@gmail.com>
 <d72c12bb0902261441w46edd0ccvdb6c5c2bc57d8372@mail.gmail.com>
Message-Id: <9EFBC0FE-38D7-4490-AA9B-4CB9E8F0D4EF@gmail.com>
From: David Van Couvering <david.vancouvering@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
In-Reply-To: <d72c12bb0902261441w46edd0ccvdb6c5c2bc57d8372@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 5G77)
Subject: Re: CouchDB and clustering
Date: Thu, 26 Feb 2009 16:42:47 -0800
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>

Isn't node failure core to the problem of partitioning because your  
partitioning of data will have to change as the cluster membership is  
changing, and data is going to have to migrate - right?

Anyway, I'll take a look at your Wiki and see if I can contribute in  
some way.  Thanks!

David

On Feb 26, 2009, at 2:41 PM, Ben Browning <ben324@gmail.com> wrote:

> On Thu, Feb 26, 2009 at 5:16 PM, David Van Couvering
> <david.vancouvering@gmail.com> wrote:
>> This us great!  Are you going to put some functional and design  
>> docs on the
>> Wiki?  This seems pretty important to get right and could save you  
>> a lot of
>> time getting feedback from the community on your overall approach.
>
>
> Yes, that sounds like a good idea. I'll find a place on the wiki to
> document my thoughts as well as the opinions of others expressed
> previously on the mailing list.
>
>
>> Just for example, a discussion of your hashing mechanism would be  
>> great, and
>> how you handle repartitioning on node failure, etc.
>
> Initially I'm just concentrating on partitioning the data. Gracefully
> handling node failures will be a step after that and I haven't put a
> lot of effort into that piece yet. Any ideas are welcome, and I know
> there are some threads that at least touched on that topic before.