Page Comparison

Content hierarchy in the docstore can be thought of as a file system with folders and files. Wherever it says "nt:folder" - think of it as behaving like a folder that can contain one or more folders and files. Wherever it says "nt:file" one can think of it as a file with actual content in it. For the MARC content hierarchy represented in the picture on the left, at L1 there can be 1 or up to 1K folders. Each MARC folder can in turn have one or up to 1K more MARC folders at L2. Each MARC folder at L2 can then have 1 or up to 1K more MARC folders at L3. Each MARC folder at L3 can then have up to 1K actual MARC files. 

Jackrabbit recommends small number of nodes per parent node for efficiency.

The total number of nodes (i.e. resulting number of files) that can be accommodated at L3 is 1M (1K * 1K), L2 is 1000M (1000 *1M) and so at L1 we can expect to handle 1000M nodes or records.

Turning on versioning for a particular node results in the creation of ~4 more nodes to maintain version info. So we can expect four times growth for data that has versioned turned on.

Instance content hierarchy is similar to the MARC content hierarchy explained above. For Instance data even though it may be represented as one single document, within the docstore the content is broken down and stored in the respective folders and files as shown in the picture on the left. At L1 there can be one or unto 1K OLEML folders. Each OLEML at L1 in turn can have one or up to 1K further OLEML folders at L2. Each OLEML folder at L2 can then have 1 or up to 1K Instance folders at L3. Each Instance folder can have one Instance file to store instance specific content and a folder for Holdings. Each Holdings folder can can contain one ore more Item files with Item specific content. The Holdings folder further contains a Holdings file with Holding specific information.
Meta data about each record for instance "dateLastUpdated", "fastAddFlag", "supressFromPublic" etc that can be part of the Instance/Holdings/Item records itself are stripped out and added as properties on the node. This can be thought of adding properties on a regular folder like the name and any other attributes.

Jackrabbit recommends small number of nodes per parent node for efficiency.

The total number of nodes (i.e. resulting number of files) that can be accommodated at L3 is 1M (1k * 1K), L2 is 1000M (1000 * 1M) and so at L1 we can expect to handle 1000M nodes or records.

Turning on versioning for a particular node results in the creation of ~4 more nodes to maintain version info. So we can expect four times growth for data that has versioned turned on.