jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KÖLL Claus <C.KO...@TIROL.GV.AT>
Subject AW: Jackrabbit 3: repository requirements
Date Wed, 10 Feb 2010 12:42:24 GMT
Here's my estimates for the Jackrabbit 3 time scale

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

One Repository with about 20 Workspaces up to hundreds of millions of documents wit a few
TB of content.
Each Workspace is used for a other application.

> * How many (concurrent) users (readers/editors/administrators) does
> your repository have?

Up to hundret concurrent readers and writers.

> * Do you need Internet-scale (millions of users or exabytes of
> content) features?


> Deployment:
> * Do you run the repository on a single server, on a cluster or in the cloud?

At the moment on a single Server and we plan now to create a Backup-Cluster.

> * How many and how powerful servers do you use for the repository?

In future 2 Servers with 8+ cores and dozens of GBs of RAM.

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

No. We create the hirarchy with a Date Pattern

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


> * 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 do not using versions.

> * How granular (hierarchies of small properties vs. big binary blobs)
> is your content?

All nodes do have a few Custom Properties. We do only have binary nodes except the hirarchy

> * How much of your content access is based on search / tree traversal
> / following references?

Mostly direct uuid access and much searches rarly references

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

Everything is strictly enforced

> * How often you modify your content model (and/or related node types)?

Till now no updates

> Features:
> * Do you need full ACID semantics? Is an "eventually consistent"
> system good enough for you?

Full ACID is needed.

> * Do you need more powerful search features than what we now have?

> * How important is observation to your application? Do you need
> trigger-like capability that can modify or reject a save() operation?

We do not use Observation.



View raw message