Newbie seeking a leg up

[Sean Dynan <se...@bigfoot.com>]

Hi all

I am just starting to investigate Jackrabbit as the content repository
for an application and some advice from the experts would seriously
speed up my evaluation.

The problem domain in question is somewhat similar to a corporate mail server:
 - Large user base
 - Frequent user reads and writes, mostly of text and
   images. By 'frequent' I mean usage on a par with an
   email client

Where it differs from the mail server comparison:
 - Users can query the repository by keyword and expect
   rapid results (think Google)
 - Users can query each other's information stores
 - No upper bound to the physical size of the repository

Right now, I don't envisage a deep-noded store. Think of many Items,
each containing content and a little bunch of metadata (e.g. datetime,
list of keywords, etc.). The email analogy would be many email
messages, each with a body and a header.

I am also thinking of implementing each user's content store as a
Workspace. Each workspace would have two top-level nodes hanging from
its root: Private and Public. Then each of those two nodes would
contain many, many content Items.

Is there anything so far that wouldn't be well served by building on
top of Jackrabbit?

Am I right in assuming (given my ideas above) that cross-workspace
queries are perfectly possible, and that all that is required is a
separate, logged-in Session to each one?

Can you envisage any issues (performance or otherwise) with my
pitifully meagre outline? Any sage words of advice on how to best
start architecting my repository?


Many thanks!
-- 
Sean Dynan

Re: Newbie seeking a leg up

[Sean Dynan <se...@bigfoot.com>]

Thanks Michael.

Yeah I'm gearing up to run a bunch of metrics (it's the only way,
right? ;-) But I was also hoping to get some insight into some advice
I'd read from mailing list archives.

1. "Use separate Write and Read repositories for high volume
applications." This doesn't sound like what I would want since there
is an implied lazy synch and I want my users to be able to see saved
content immediately (not at some arbitrary time in the future).

2. "A deep-noded workspace may be more efficient/speedy for updates
than a shallow, wide workspace." Again, this makes me pause for
thought since I envisage my repository 'schema' being wide rather than
deep.

I guess I'm hunting for some Jackrabbit best practices, if such things exist.

Thanks.

-- 
Sean Dynan


On 9/4/06, Michael Neale <mi...@gmail.com> wrote:
> Hi Sean.
>
> I was also looking in to how Jackrabbit behaved for my needs (I had some
> specific numbers I was looking for) - the best thing I found was to just
> build up some basic test code to load up enough nodes to verify it would do
> roughly what I needed (which was a bit more effort then I thought, but I got
> there in the end).
>
> The moral of the tale: try it ! hack away and see how it behaves. For a
> large flat structure like you are suggesting, it seems that save operations
> can be a little slow (but slow is relative, in terms of user experience its
> still fast) for large numbers of nodes under the same parent, but otherwise
> seemed fine (I was also concerned with versioning a lot, which I am not sure
> concerns you).
>
> On 9/4/06, Sean Dynan <se...@bigfoot.com> wrote:
> >
> > Hi all
> >
> > I am just starting to investigate Jackrabbit as the content repository
> > for an application and some advice from the experts would seriously
> > speed up my evaluation.
> >
> > The problem domain in question is somewhat similar to a corporate mail
> > server:
> > - Large user base
> > - Frequent user reads and writes, mostly of text and
> >    images. By 'frequent' I mean usage on a par with an
> >    email client
> >
> > Where it differs from the mail server comparison:
> > - Users can query the repository by keyword and expect
> >    rapid results (think Google)
> > - Users can query each other's information stores
> > - No upper bound to the physical size of the repository
> >
> > Right now, I don't envisage a deep-noded store. Think of many Items,
> > each containing content and a little bunch of metadata (e.g. datetime,
> > list of keywords, etc.). The email analogy would be many email
> > messages, each with a body and a header.
> >
> > I am also thinking of implementing each user's content store as a
> > Workspace. Each workspace would have two top-level nodes hanging from
> > its root: Private and Public. Then each of those two nodes would
> > contain many, many content Items.
> >
> > Is there anything so far that wouldn't be well served by building on
> > top of Jackrabbit?
> >
> > Am I right in assuming (given my ideas above) that cross-workspace
> > queries are perfectly possible, and that all that is required is a
> > separate, logged-in Session to each one?
> >
> > Can you envisage any issues (performance or otherwise) with my
> > pitifully meagre outline? Any sage words of advice on how to best
> > start architecting my repository?
> >
> >
> > Many thanks!
> > --
> > Sean Dynan

Re: Newbie seeking a leg up

[Michael Neale <mi...@gmail.com>]

Hi Sean.

I was also looking in to how Jackrabbit behaved for my needs (I had some
specific numbers I was looking for) - the best thing I found was to just
build up some basic test code to load up enough nodes to verify it would do
roughly what I needed (which was a bit more effort then I thought, but I got
there in the end).

The moral of the tale: try it ! hack away and see how it behaves. For a
large flat structure like you are suggesting, it seems that save operations
can be a little slow (but slow is relative, in terms of user experience its
still fast) for large numbers of nodes under the same parent, but otherwise
seemed fine (I was also concerned with versioning a lot, which I am not sure
concerns you).

On 9/4/06, Sean Dynan <se...@bigfoot.com> wrote:
>
> Hi all
>
> I am just starting to investigate Jackrabbit as the content repository
> for an application and some advice from the experts would seriously
> speed up my evaluation.
>
> The problem domain in question is somewhat similar to a corporate mail
> server:
> - Large user base
> - Frequent user reads and writes, mostly of text and
>    images. By 'frequent' I mean usage on a par with an
>    email client
>
> Where it differs from the mail server comparison:
> - Users can query the repository by keyword and expect
>    rapid results (think Google)
> - Users can query each other's information stores
> - No upper bound to the physical size of the repository
>
> Right now, I don't envisage a deep-noded store. Think of many Items,
> each containing content and a little bunch of metadata (e.g. datetime,
> list of keywords, etc.). The email analogy would be many email
> messages, each with a body and a header.
>
> I am also thinking of implementing each user's content store as a
> Workspace. Each workspace would have two top-level nodes hanging from
> its root: Private and Public. Then each of those two nodes would
> contain many, many content Items.
>
> Is there anything so far that wouldn't be well served by building on
> top of Jackrabbit?
>
> Am I right in assuming (given my ideas above) that cross-workspace
> queries are perfectly possible, and that all that is required is a
> separate, logged-in Session to each one?
>
> Can you envisage any issues (performance or otherwise) with my
> pitifully meagre outline? Any sage words of advice on how to best
> start architecting my repository?
>
>
> Many thanks!
> --
> Sean Dynan
>

Re: Newbie seeking a leg up

[David Nuescheler <da...@gmail.com>]

Hi Sean,

> Will do. We're hoping to run some basic tests in a couple of days.
Looking forward to that.

> Yep. We were part of the way towards implementing our own content
> repository when we found JSR-170. Our main user requirement is a
> snappy user experience, which equates to rapid query results.
The "Content Model" can certainly affect your performance more than
anything else. In my experience using hierarchies in a smart way
can help avoiding a lot of queries. I can certainly see a difference
between a traditional RDB data model and a good "Content
Model", so if you don't mind sharing your content model we may be
able to propose optimizations, based on the Jackrabbit internals
and your application needs.

> Hopefully JackRabbit will fit the bill, like most Jakarta
> projects do ;-).
As mentioned above, sometimes the "Content Model"
makes all the difference.

regards,
david

Re: Newbie seeking a leg up

[Sean Dynan <se...@bigfoot.com>]

On 9/4/06, Sean Dynan <se...@bigfoot.com> wrote:
>
>
> Many thanks Michael.
>

You are, of course, David and I am an idiot in too much of a rush. Sorry.
-- 
Sean Dynan

Re: Newbie seeking a leg up

[Sean Dynan <se...@bigfoot.com>]

On 9/4/06, David Nuescheler <da...@gmail.com> wrote:
> > I am also thinking of implementing each user's content store as a
> > Workspace. Each workspace would have two top-level nodes hanging from
> > its root: Private and Public. Then each of those two nodes would
> > contain many, many content Items.
>
> Given your requirements that you would like users to
> query each others "information stores", I wanted to ask
> if a user can query only the "Content" of any single other
> users at a time or would you like to query all the content
> with a single query? (Obviously respecting access control)
>
> If yes, I would recommend to store all the "home directories"
> in a single workspace, since this would allow to query with
> a single query.

Nothing is written in stone for us yet. We will happily place all
users' content in a single workspace if that makes the best
architectural sense.


> > Is there anything so far that wouldn't be well served by building on
> > top of Jackrabbit?
> Personally, I think this is a very well suited set of requirements
> for a JCR-based application.

Cool :-)


> > Am I right in assuming (given my ideas above) that cross-workspace
> > queries are perfectly possible, and that all that is required is a
> > separate, logged-in Session to each one?
> Queries operate on a single workspace.
>
> In your scenario there is not really a drawback of using a single
> workspace, or in other words not really a need to incurr the
> overhead of a "per user workspace". Multiple workspaces become
> a requirement if you want to leverage the cross-workspace
> methods such as merge(), update(), clone() etc...

Okay. That makes sense.


> > Can you envisage any issues (performance or otherwise) with my
> > pitifully meagre outline? Any sage words of advice on how to best
> > start architecting my repository?
> I think using JCR for an application like yours is great.
> I would also recommend to hack away and inform this list of
> possible perfomance bottlenecks that you run into.

Will do. We're hoping to run some basic tests in a couple of days.


> The good news about using a standard like JCR is that you
> are not bound to a single implementation, meaning that if
> you find out, a couple of years down the road that Jackrabbit
> doesn't cover your performance needs anymore you can
> always switch to commercial or other opensource alternatives.

Yep. We were part of the way towards implementing our own content
repository when we found JSR-170. Our main user requirement is a
snappy user experience, which equates to rapid query results.
Hopefully JackRabbit will fit the bill, like most Jakarta projects do
;-).

Many thanks Michael.

-- 
Sean Dynan

Re: Newbie seeking a leg up

[David Nuescheler <da...@gmail.com>]

Hi Sean,

Thanks for sharing the Info.

> I am also thinking of implementing each user's content store as a
> Workspace. Each workspace would have two top-level nodes hanging from
> its root: Private and Public. Then each of those two nodes would
> contain many, many content Items.

Given your requirements that you would like users to
query each others "information stores", I wanted to ask
if a user can query only the "Content" of any single other
users at a time or would you like to query all the content
with a single query? (Obviously respecting access control)

If yes, I would recommend to store all the "home directories"
in a single workspace, since this would allow to query with
a single query.

> Is there anything so far that wouldn't be well served by building on
> top of Jackrabbit?
Personally, I think this is a very well suited set of requirements
for a JCR-based application.

> Am I right in assuming (given my ideas above) that cross-workspace
> queries are perfectly possible, and that all that is required is a
> separate, logged-in Session to each one?
Queries operate on a single workspace.

In your scenario there is not really a drawback of using a single
workspace, or in other words not really a need to incurr the
overhead of a "per user workspace". Multiple workspaces become
a requirement if you want to leverage the cross-workspace
methods such as merge(), update(), clone() etc...

> Can you envisage any issues (performance or otherwise) with my
> pitifully meagre outline? Any sage words of advice on how to best
> start architecting my repository?
I think using JCR for an application like yours is great.
I would also recommend to hack away and inform this list of
possible perfomance bottlenecks that you run into.

The good news about using a standard like JCR is that you
are not bound to a single implementation, meaning that if
you find out, a couple of years down the road that Jackrabbit
doesn't cover your performance needs anymore you can
always switch to commercial or other opensource alternatives.

regards,
david