Posts Tagged ‘OUD’

nosql-textGot a question from a customer on if it was a good idea to drop their LDAP directory in favor of a NoSQL repository.  For what they needed to do, they felt it freed them to have a more flexible architecture.  This follows up another client request who wished our directory products were based on a NoSQL data repository.

For those not keeping up with data repository trends, SQL has dominated the standards as a way to retrieve data from a relational database (dumb statement of the month). In theory, it abstracts the underlying repository so SQL could be used to pull information out of any vendor’s compliant product.  It works great in joining information together, such as transactions, from the underlying tables.

But not all data fits neatly into this SELECT, JOIN, table paradigm, including directory objects.  A more object oriented approach to data storage is the right way to go.  inetOrgPerson, the de facto standard of how to store information about a user in a directory is actually made up of several objects that inherent the other. To paraphrase Genisis, Top begat User begat Person begat InetOrgPerson or something like that.  To build an SQL statement that could retrieve or store all the information contained in the inetOrgPerson object would be complicated and complex using at least three joins.

The SQL statement would be complex to build and require the SQL engine to decompose it during execution. Overhead to build the statement, overhead to process it.  Kills performance which is the enemy of a good directory.

Instead, the developer should just be able to build the inetOrgPerson and trigger is serialization into the data repository and let the database figure out how to store the information.  Much simpler and, most importantly for a directory, much faster.

So to get back to the original question, should they pull the LDAP directory out and go with a NoSQL repository directly?

My answer is the typical consulting “it depends”.  If this is a stand alone application and all you need to do is store some key-value pairs, it will be hard to argue against going with the NoSQL repository.  But I would suggest you think long and hard about dropping the LDAP directory layer.

For two reasons. One, LDAP brings more than just data storage.  It has years of standards built into it, such as the inetOrgPerson and the ACI rules and policies to access of the objects.  That would have to be recreated at the database level. Second is the fact that many of the newer LDAP directories out there already are adopting object oriented repositories underneath. One of the main reasons my company Oracle came out with a new directory, Oracle Unified Directory(OUD), is to take advantage of the embedded Berkeley DB Java Edition technology.  As OUD is written in pure Java, it made the underlying repository, and thus the overall directory, faster, more robust, and highly scalable.

Good news is you can take advantage of this NoSQL storage approach, but still treat the directory as an LDAP repository, easing migration and upgrade costs.

Read Full Post »