couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Browning <>
Subject Re: Partitioning use cases
Date Sun, 01 Mar 2009 23:05:04 GMT

On Fri, Feb 27, 2009 at 7:16 PM, David Van Couvering
<> wrote:
> Hi, all.  I did a first pass at the high-level use cases, both to start with
> and then looking forward.

Thanks for adding to the document :)

> I'm sure I'm missing some things (in particular, I don't fully understand
> the discussion about configuring the topology differently depending upon
> performance needs - I wonder if that's an implementation-specific detail).

>From what I understand, the initial idea was to have the partitioning
be fairly static and not try to tackle all the dynamic challenges
up-front. So initially a topology would be decided upon based upon the
needs of a particular dataset (data-intensive, map/reduce intensive,
etc) and remain fairly stable.

> One way perhaps I could help is to work on an API that maps a key to a node
> (with some sort of pluggable interface for various consistent hashing
> algorithms, starting maybe with Chord, given that there is an existing
> implementation in Erlang called Chordial -

I think having a pluggable interface for choosing the consistent
hashing algorithm is a good idea. Chord looks very nice for systems
where nodes are dynamically added and removed all the time. I think
that's a bit more advanced than the initial implementation is shooting
for but maps very well to the long-term goal with CouchDB as a true
distributed database.

These are my thoughts, so if they don't map with the opinions of the
rest of the community please speak up.


View raw message