Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <B06CA9F4-2A66-4E6C-BE1A-925D7821CBCE@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <27d8d0930809231715v379b8d27jd830af5c33ecda8f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Newbie questions
Date: Wed, 24 Sep 2008 09:46:11 +0200
References: <27d8d0930809231715v379b8d27jd830af5c33ecda8f@mail.gmail.com>


On Sep 24, 2008, at 2:15 , Ayende Rahien wrote:

> First, I must admit that I am a complete newbie with Erlang.
> Nevertheless, I tried to read couch db source in order to see if I can
> actually understand what is going on.
> You can see the results here:
> http://ayende.com/Blog/archive/2008/09/24/reading-erlang-inspecting-couchdb.aspx

>
> I would be happy if someone could point out all the gross  
> inaccuracies that
> are undoubtedly there.

I'm only halfway through, but I'll send in my comments soon.


> Anyway, I had a few questions that I hope I'll be able to get some  
> answers
> for.
> merge conflicts - how does couch db decides on "best" revision?

It arbitrarily choses one revision. The only guarantee that is made is  
that for
the same conflict all nodes in a CouchDB cluster choose the same latest
revision to ensure data consistency.


> does couchdb store all documents on all servers? implements sharding?
> from browsing the code, it seems like all documents exists on all  
> servers,

For the moment, yes all docs on all nodes, but we will have sharding.  
Also,
consistent hashing in your data storage layer could already emulate  
that.


> and it is up to the servers management to decide how to replicate  
> between
> them. Something like master / 2 slaves between each three nodes  
> should do
> quite well, I imagine.

Correct.


> Two questions that are of particular interest to me, and I haven't  
> been able
> to get from the code so far are:
> - How is the data stored? I think that it is a binary tree on disk,  
> but I am
> not following how updates to that can be safe to do so with ACID  
> guarantees.

Writes are serialized. Only one write can happen at a time and it is  
completely
flushed and committed to disk (2 x fsync()) before another write comes  
in. Writes
are append-only. No data is ever overwritten. This gives us the ACID &  
MVCC
buzzcronyms :-)


> - How are views stored?

In the same way as a database.


Cheers
Jan
--