Friday, May 24, 2013

Comparing Oracle NoSQL and MongoDB features

I recently had a chance to go through Oracle documentation on its NoSQL solution in an effort to evaluate it against MongoDB. The below comments are based on Oracle's 11g Release 2 document (4/23/2013) while Mongo is at its Release 2.4.3.

Oracle's deployment architecture for its NoSQL solution bears strong resemblance to MongoDB with some restrictions which I feel will go away in subsequent releases. The whole system is deployed using a pre-decided number of replica sets where each replica set may have a master and several slaves. The durability and consistency model also seems similar to what MongoDB offers, although the explanation  and control seemed a lot more complex. One of the restrictions is that the user must decide how many partitions the whole system will have in the beginning itself and these partitions are allocated amongst the shards. Mongo's concept of "chunks" seemed a lot similar but easier to use and understand. 

One of the biggest issues is security - the system has almost no security at user access level and there is no command line shell to interact with it. The only API which can possibly be used is Java. This is clearly not developer friendly right now. 

Perhaps the most confusing was the concept of JSON schemas which were used to save and retrieve the values in the key value database. Every time you save and retrieve a value from the database you have to specify a schema to serialize and de-serialize the data and these schemas may have different versions that you need to track. There could be multiple schemas concurrently being used (e.g each table could be using one schema). What was confusing about it was why Oracle took this approach and even if they did why was this not hidden under the hood so users dont have the deal with it. The boilerplate code which has to be written to constantly handle this simply looks unreadable and no developer would find it fun to use this system.

I also noticed the absence of ad-hoc indexing in the system, something I have begun to appreciate in Mongo now.

Another odd feature was that when an update was made to a set of records which has the same "major" key, the update could be made as a transaction. This was because a records which had the same "major key" always went to the same partiton which ends up on a single replica set and hence on one physical node which is acting as a master. This is one more thing which must be carefully considered by the developer before the schema is designed.

I found Mongo to be much more mature in terms of using true flexible schema - the user sees records as full JSON documents where each record in the same table can potentially have different fields. In Oracle, if a field is missing and its in the schema it must have a default value (very much like relational).

What seemed to be well thought through was the deployment architecture, durability, consistency model and how it was controlled by the user on a per operation basis. I am not sure of any big deployments using Oracle NoSQL yet so it would be good to hear if there are any. I am also expecting a big revamp in the next release from Oracle so this is easier to use from a development standpoint.