For enterprise architects and software developers interested in exploring a vast array of options for managing application data, the choice in data persistence solutions is no longer limited to the relational world, as the range and depth of NoSQL options has become an embarrassment of riches. MongoDB, Cassandra, CouchBase, NeoJ4, VoltDB, ElasticSearch and Reddis makes up only a short list of the various NoSQL options available. Almost anything you want to do can be done using the various NoSQL database products on the market today. But as any software architect knows, it is not always possible to get everything that is needed from a single database product. As a result, seasoned professionals aren't afraid to Hadoop together a combination of database solutions to approximate what is really needed. Of course, since there are so many different factors involved with NoSQL, this can rapidly become a challenge. Some of the options and features an application architect needs to consider when choosing a solution for handling persistence include:
- Programming languages
- Querying languages
- Reporting functions
- Hardware or infrastructure requirements
- Operating systems and more
NoSQL, no standards, no end in sight
Many enterprises are simply trying to decide what’s most important and are thusly implementing the NoSQL solution that comes closest to delivering what they need right now. Then, they cross their fingers and hope that they don’t have to switch vendors anytime soon. They know deep down that even in an age of less contractual and licensing red tape, portability would be a huge problem. The lock in is a byproduct of the fact that there are no standards.
Ann Kelly and Dan McCreary, coauthors of Making Sense of NoSQL, have plenty to say about this dearth of standardization. That is after all, one of the things that seems to make NoSense in the NoSQL world. Other authors have claimed that the lack of standardization is simply an unavoidable feature of having such a wide variety of solutions. But that’s kind of a cop-out. Kelly points out that all you have to do to uncover the real reason is to follow the money. It’s not in the short term financial interest of venture capitalist firms to support standards. "They’re goal up front is to get a return on their investment. You don’t get that by investing in standards. You can only get a return on your investment if your solution is unique enough for people to adopt it."
The splintered nature of the current NoSQL market creates an ideal environment to maximize short term profits. Of course, in the long term, it will pay off to have standards. The few niche players that survive the blood bath and become the standard setters will attract lots of third party developers, helping grow demand for their products.
The push towards standardization
The idea that there’s simply nothing that can be done isn’t accurate either. McCreary revealed that useful and relevant standards are already available. It’s just that efforts to make them relevant industry-wide have been spotty. "There are standards that NoSQL developers could implement. In fact, there are third parties that are grafting them on. There are two separate efforts now to put XQuery interfaces on MongoDB. That means I could port my data between MarkLogic which is a native XML system and MongoDB and maybe 3 other native XML databases that have good scale characteristics."
The present may look muddled, but there is hope for the future. As McCreary says, "Standards are beautiful, wonderful things, but you cannot predict when they’re going to be adopted. There are uncontrollable events that suddenly allow them to take off." As the Sam Cooke song says, change is gonna come. We just don’t know when or from what direction. All it took was Steve Jobs saying, "No Flash on Apple products, ever!" to get the ball rolling on SVG standards. So, there may be a corresponding flashpoint for NoSQL in the commercial field as well. That will be a glad day. Software architects are waiting with baited breath for a champion to appear, and for standards to be the norm when it comes to working with NoSQL solutions.