Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of ianboston@gmail.com
 designates 74.125.82.174 as permitted sender)
MIME-Version: 1.0
Sender: ianboston@gmail.com
In-Reply-To: <CE82B435.4B109%mueller@adobe.com>
References: 
 <CAB+dfi=mbj6wLpCRoXLY813aNTqM4Yww+arer3kTyUQgyNizNA@mail.gmail.com>
	<CE82B435.4B109%mueller@adobe.com>
Date: Tue, 15 Oct 2013 08:32:44 +0100
Message-ID: 
 <CAH=Gj-=OXokgnGO_G8kZbzbhwqZKDqyWgeymUHb8v_jOz_r5Rg@mail.gmail.com>
Subject: Re: content hash of a tree
From: Ian Boston <ieb@tfd.co.uk>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 15 October 2013 08:13, Thomas Mueller <mueller@adobe.com> wrote:
> Hi,
>
>>I thought this was one of the fundamental principles that
>>allow for quick diff/merge and help identify a commit within the MVCC
>>timeline.
>
> I'm not sure where you heard or read that, but a content hash is not
> needed for this; a revision number that is changed whenever there is a
> modification is enough. (For each change in this node or any direct or
> indirect child node.) For the MongoMK, the revision is a combination of
> the timestamp, the cluster node id, and a counter; very similar to the
> MongoDB object id: http://docs.mongodb.org/manual/reference/object-id/
>
>>what was the reason to abandon this idea?
>
> As for the MongoDB: performance and scalability. A node lookup by content
> hash would be bad for performance, as it would require an index on a
> randomly distributed data. See also
> http://fr.slideshare.net/daumdna/mongodb-scaling-write-performance - page
> 9 (the red line is with an index on the content hash, the green line
> without). But even without such an index: maintaining the content hash
> would be prohibitively expensive and would prevent scalable writes.

With the current state of Oak, is Oak on Cassandra possible ?
Slide 45.
Ian

>
> Regards,
> Thomas
>