You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2010/02/17 16:33:58 UTC
[jr3] Unified persistence
Hi,
In addition to the search index (that deserves it's own thread), we
have various different mechanisms for persisting repository
information:
persistence managers for node and property states
data store for binary properties
journal for cluster synchronization records
file system abstraction for various minor things like:
custom_nodetypes.xml for registered node types
ns_reg.properties for registered namespaces
rootUUID file for the root node UUID (essentially a constant)
workspace.xml for workspace configuration
locks for open-scoped locks
Most information that we store in the repository is duplicated in at
least two of these locations. Reducing the amount of different storage
formats and mechanisms we use would make a lot of things easier.
Ideally we'd have a single clustered persistence layer that we could
use for all of these things (and the search index).
How can we achieve something like that?
BR,
Jukka Zitting
Re: [jr3] Unified persistence
Posted by Ian Boston <ie...@tfd.co.uk>.
On 19 Feb 2010, at 08:43, Marcel Reutegger wrote:
> 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?
IIUC, provide the API accepts that eventual consistency exists and knows which version of the root node or modification is current then all nodes can act accordingly.
It would be very useful to have this built into the persistence API and any journaling/cluster so that other eventually consistent storage providers can be used eg Cassandra or Voldemort. (as well as shared rdbms storage, which would not care)
For example, in the current PM, if a node in cluster knows via the journal that an item came from an out-of-date root node, and it also knows which nodes have the required root node, it can go direct just consistent enough location to get that item. I think this is possible in the current PM + Journal impl, but requires some additional information in the events.
It would be interesting to know some stats on consistency latency in a real cluster for the above.
In Cassandra you can tune it to suite your needs [1], so you could balance locating a node with the right root version with the cost of doing that if not local.
Ian
1 http://wiki.apache.org/cassandra/API
>
> another implementation that comes to my mind is apache hbase.
Re: [jr3] Unified persistence
Posted by Marcel Reutegger <ma...@gmx.net>.
hi,
On Wed, Feb 17, 2010 at 17:29, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Feb 17, 2010 at 5:00 PM, Alexander Klimetschek <ak...@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.
regards
marcel
> BR,
>
> Jukka Zitting
>
Re: [jr3] Unified persistence
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Feb 17, 2010 at 5:00 PM, Alexander Klimetschek <ak...@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.
BR,
Jukka Zitting
Re: [jr3] Unified persistence
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Feb 17, 2010 at 16:33, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> In addition to the search index (that deserves it's own thread), we
> have various different mechanisms for persisting repository
> information:
>
> persistence managers for node and property states
> data store for binary properties
> journal for cluster synchronization records
> file system abstraction for various minor things like:
> custom_nodetypes.xml for registered node types
> ns_reg.properties for registered namespaces
> rootUUID file for the root node UUID (essentially a constant)
> workspace.xml for workspace configuration
> locks for open-scoped locks
>
> Most information that we store in the repository is duplicated in at
> least two of these locations. Reducing the amount of different storage
> formats and mechanisms we use would make a lot of things easier.
>
> Ideally we'd have a single clustered persistence layer that we could
> use for all of these things (and the search index).
>
> How can we achieve something like that?
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. But all the
type constraints, versioning etc. JCR features are only done on a
higher level. This could make it easier to use the lower-level
persistence for things like the above w/o necessarily breaking JCR
contracts. An import/export on this level could also be used for fast
and full-coverage backups and dumps.
These parts could then be made accessible via the JCR API selectively,
but eg. read-only (for those where JCR defines a separate API, egg.
namespace registry, node types).
The main advantage however, would be that of more flexibility in
writing the persistence layer and optimizing it for performance.
Currently many things are entangled (eg. child node entry list of
nodestates, see JCR-642) across many layers.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jr3] Unified persistence
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Feb 18, 2010 at 08:44, Thomas Müller <th...@day.com> wrote:
> About 'append only' and 'immutable' storage. Here is an interesting link:
>
> http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence/
Nice article. Using such "purely functional trees", you get
copy-on-read for free, and this can also be used to implement
versioning.
Since the versioning in JCR is shared by all workspaces, it makes
sense to put everything into a big tree (as discussed in the other
thread).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jr3] Unified persistence
Posted by Thomas Müller <th...@day.com>.
Hi,
About 'append only' and 'immutable' storage. Here is an interesting link:
http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence/
Regards,
Thomas
Re: [jr3] Unified persistence
Posted by Stefan Guggisberg <st...@gmail.com>.
On Wed, Feb 17, 2010 at 5:42 PM, Thomas Müller <th...@day.com> wrote:
> Hi,
>
> I would implement the storage layer ourselves. It could look like:
>
> - FileDataStore: keep as is (maybe reduce the directory level by one).
>
> - Each node has a number (I would use a long). Used for indexing.
>
> - MainStorage: the node data is kept in an append-only "main
> persistence storage". When switching to a new file, the node lookup
> table (node index) is appended. An optimization step would separate
> less updated nodes ("old generation") and frequently updated nodes.
> Nodes and its child nodes are grouped together.
>
> - Namespace index, name index, nodetype registry: start with a fixed
> (hardcoded) list, and store additional entries as system nodes.
i like this approach, +1
cheers
stefan
>
> Regards,
> Thomas
>
Re: [jr3] Unified persistence
Posted by Thomas Müller <th...@day.com>.
Hi,
I would implement the storage layer ourselves. It could look like:
- FileDataStore: keep as is (maybe reduce the directory level by one).
- Each node has a number (I would use a long). Used for indexing.
- MainStorage: the node data is kept in an append-only "main
persistence storage". When switching to a new file, the node lookup
table (node index) is appended. An optimization step would separate
less updated nodes ("old generation") and frequently updated nodes.
Nodes and its child nodes are grouped together.
- Namespace index, name index, nodetype registry: start with a fixed
(hardcoded) list, and store additional entries as system nodes.
Regards,
Thomas