First, I would say that the majority of my issues come from the fact that I was attempting to migrate a good sized amount of content from crx2 to crx3. However, the issues I have with OAK/MongoDB are pretty significant.
1. Having a remote JCR is not like having a remote data store for some content on a traditional webserver. Unlike other platforms, everything is in the JCR. Everything; your code, configurations, images. Everything is content and it's somewhere else. In fact this is such an impact that the OAK team has gone to great strides to facilitate caching so that after they've moved everything to a remote data store, they could then store it back locally. 2. MongoDB was a poor choice for OAK. The JCR specification detailed the ability to have a point in time view of the content repository. This is a usually referred to as MVCC and a lot of databases have this capability by default so that you can grab a timestamp /id/session key and maintain a consistent view. MongoDB 2.x doesn't have this. So instead of using something that comes OOTB for the majority of db's the OAK team had to implement their own MVCC on top of the data. 3. Additionally, possibly because of a lack of MVCC, indexing on the MongoDB blocks the table it's indexing. So the OAK team appears to have implemented their own index tables instead of using the native indexing. This has the side issue of indexing being performed by the OAK implementation, which is on the front end. Resulting in a far slower indexing experience on Mongo then you would if you used local store. Additionally. In CRX2 everything was indexed. Which made it far easier to make performant queries but had the side effect of huge repositories. In OAK, nothing is indexed unless you say so. Much like a traditional DB table. So telling someone that someone can make a query against any property is true. But if you have a large amount of data, that query is going to be painfully long unless you index correctly. 4. AEM backtracking. If you go to the documentation site for AEM, the documentation that I used to choose Mongo for our Architecture isn't there anymore. There has been a culling of references to MongoDB and it's usage. Right now, if you were to contact their support team, they only recommend it for use if your Data is too large for the TarMK solution, and in their documentation they suggest that you have an AEM architect review what you're doing before using it. I should clarify that the problems I've seen isn't with MongoDB itself. It's with the OAK implementation of the JCR on top of MongoDB that appears to be problematic. -Jason -----Original Message----- From: Olaf [mailto:[email protected]] Sent: Monday, November 16, 2015 11:19 AM To: [email protected] Subject: RE: Resource class vs CND Hi Jason, That sounds interesting! Would you mind providing a bit more detail as to why you would advise against it? Regards, Olaf
