jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: Jackrabbit 3: repository requirements
Date Wed, 17 Feb 2010 22:17:35 GMT
Hi Jukka,

Interesting to see how we can get Jackrabbit ready for the next decade ;-)

Here is my feedback for the survey.


> Scalability:
> * How much content (number of documents/nodes, raw amount data in
> GB/TB/PB) do you have in the repository?
In the order of tens of millions of nodes and tens of GB of data.

> * How many (concurrent) users (readers/editors/administrators) does
> your repository have?
readers: tens of thousands, concurrent editors: hundreds, admins:  just a few.

> * Do you need Internet-scale (millions of users or exabytes of
> content) features?
We will probably not go over serveral TBs of data and hundred of
thousands of users in the next few years.

>
> Deployment:
> * Do you run the repository on a single server, on a cluster or in the cloud?
Usually custom clusters, but we're looking at (private) cloud options.

> * How many and how powerful servers do you use for the repository?
Between 2 to 16.

>
> Content model:
> * Do you need support for flat content hierarchies (>>10k sibling nodes)?
Yes!

> * Do you need support for same-name siblings?
Not really.

> * If you use versioning, how actively (commit on all saves / commit
> only at major milestones) and for what purpose (revision history,
> backup, etc.) do you use it?
We use versioning actively  on workflow steps like publish, take
offline, save document, etc.

> * How granular (hierarchies of small properties vs. big binary blobs)
> is your content?
Lot's of small properties, but also blobs up to 100MB, but we would
like to store larger blobs for things like movies.

> * How much of your content access is based on search / tree traversal
> / following references?
We use searches and tree traversal a lot, but we try to avoid (hard) references.

> * How much you rely on the repository to enforce your content model
> (node type constraints, etc.)?
We use strictly enforced content models.

> * How often you modify your content model (and/or related node types)?
Often, but not as often as we would like, because changing nodetype
definitions is quite a difficult and heavy operation right now.

> Features:
> * Do you need full ACID semantics? Is an "eventually consistent"
> system good enough for you?
"eventually consistent" would be good enough in most cases.

> * Do you need more powerful search features than what we now have?
Always nice to have, but I don't have any specific features in mind. ;-)

> * How important is observation to your application? Do you need
> trigger-like capability that can modify or reject a save() operation?
We mostly need some async (persistent) events for which we use
observations right now. Triggers that can "veto" operations would be a
nice addition.

Regards,
Bart

Mime
View raw message