Julian,
Testing on the current version of jackrabbit shows significant reduction is performance when we hit upwards of 100K documents. This sound like you are storing all documents in a flat list within a single parent node. This is a known (design) limitation in Jackrabbit. You should be able to work around this by creating a hierarchy and store < 10k documents within a single parent node. With such a structure storing 1 million documents should not cause performance problems. Our test did not use a flat list. We have our content hierarchy that starts at /inmedius/content/main But under that is where we start our 'projects'. Which is a new node for each project, and under each project is our actual document content My test was to attempt to insert 1 million documents in the system to determine if it could handle it and evaluate the amount of time it took to insert the documents. Did it slow down? I never reached 1 million as my test system utilized oracle XE and we ran out of db space, But the test was such that I would add node under main, and add 1000 documents under that node. Then spit out the time it took to insert. This was done as many times until we maxed the db. The trend of time on insert was it increased. Oak can handle larger child lists, as long as the parent node is not orderable. Hope this helps. Regards Julian On Mon, Nov 10, 2014 at 6:08 PM, O'Donnell, Laura <[email protected]> wrote: Our company is currently using jackrabbit embedded into our product. We run on JBoss and access jackrabbit through JCA, and have stored the jackrabbit content in an oracle database. Our current product is being revamped to be able to handle as much as 1 million documents, so we need a responsive repository that can do the same. Testing on the current version of jackrabbit shows significant reduction is performance when we hit upwards of 100K documents. So, we are looking for alternatives. OAK obviously is the first question. However, in order to consider OAK we need to know the following? Can OAK run in JBOSS like jackrabbit did? Can we use an Oracle or MySQL db to store the OAK content? Is there a plan to expose a build that we can use instead of requiring users to compile the source and then try to figure out which jars are necessary? If the answer is no to the above questions, is there a timeframe where any of the above are planned to be available? We are at a point where we need to decide whether OAK should even be considered within our plans, so any information on the above would be appreciated. Thanks, Laura O'Donnell
