jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [jr3] Unified persistence
Date Fri, 19 Feb 2010 08:43:48 GMT

On Wed, Feb 17, 2010 at 17:29, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Wed, Feb 17, 2010 at 5:00 PM, Alexander Klimetschek <aklimets@day.com> wrote:
>> I think a good idea (and I guess this is what you have in mind) would
>> be to have a lower-level persistence API that is journal/cluster-aware
>> and allows for all the basic node and property storage.
> Agreed. The big question related to this is whether we should try to
> implement this layer ourselves or if we should rather look at existing
> solutions like clustered/distributed databases (either relational or
> NoSQL). The former would probably give us the best theoretical
> performance as we could design the low-level storage model around the
> content hierarchy, while the latter would save us years worth of work.
> Personally I think we should go with an existing solution and
> implement the JCR content hierarchy on top of that, just like we
> currently do with the JDBC-based persistence managers. Instead of
> relational databases, I'm especially interested in solutions like
> distributed hash tables (Project Voldemort, etc.) or databases
> (Cassandra, etc.) that are based on the idea of eventual consistency
> and offer an easy way to scale horizontally in a cloud environment.

I think we should try to abstract from a concrete underlying
persistence layer, like we currently do. I know this adds overhead but
it makes it possible to have alternative back-ends. In addition, I
think it helps us to better understand what the contract between the
lower-level API and the implementation above is. e.g. how does
eventual consistency affect the API? how do we have to design it, to
make it useable?

another implementation that comes to my mind is apache hbase.


> BR,
> Jukka Zitting

View raw message