At the same time, the rise of Object Relational Mapping (ORM) within the NoSQL space is impressive. Multiple approaches and frameworks are competing within the same solution space and I can’t stop wondering whether they do not enter the market too soon … Don’t get me wrong. I strongly believe in the advantages of using an ORM. In fact, I can not even remember my last enterprise-type application that is not powered by an ORM. So why am I expressing my concerns in case of NoSQL?

Relational databases have been around for the past thirty or more years. We have all done our own share of low-level database work and have been exposed to the overal technicalities of a RDBMS. As a result, when advancing to the use of an ORM, people can count on this basic knowledge set when problems are encountered. Most of us however, lack this type of in-depth NoSQL expertise. Nevertheless, as the NoSQL hype is growing, people will fall back on their ORM expertise in order to quickly adopt this new technology. This is enforced by the motivation of several NoSQL ORM frameworks: “Don’t mind the NoSQL complexities. Just employ an approach you already know!”. Unfortunately, all abstractions will fail you at some point in time …

But what about the mapping-side of things? First of all, various NoSQL approaches, including document-based databases, don’t exhibit the object-oriented impedance mismatch. In approaches that do, an ORM will not always make sense. Several ORMs target a variety of NoSQL technologies by providing a generic mapping framework: “Map your objects. Don’t care about the target NoSQL technology. We’ll do that.”. Unfortunately, this approach will fail you at achieving the true (performance) promise of NoSQL. An ORM framework would not have been able to help me at attaining the performance gains as described in one of my previous articles. In fact, it would not even make sense to implement the problem domain as such. Hence, I’m afraid that the use of an ORM framework will disappoint a lot of NoSQL newcomers …

ORM frameworks in the NoSQL space will however get us closer to the idea of Polyglot Persistence. Spring Data Graph for instance, allows you to map Pojos in such a way that parts of it are persisted to a traditional database and parts of it to the Neo4J graph database. This is achieved in a technical transparant way, making it an easy-to-use solution. Nevertheless, I still feel it’s way too soon for ORMs as the knowledge and best practices on NoSQL are just being developed.

At various occasions during the meeting, the Bigness of Big Data was discussed. Questions were raised concerning the number of nodes people deploy within their Big Data cluster, the number of Gigabytes of data people are storing, etc … Although these are all valid questions, I sometimes get the feeling that people are focusing too much on the ‘Big’-aspect of Big Data; if you explain to people you are running a NoSQL application on a single node, they generally do not consider it to be a Big Data solution …

For me personally, being able to easily scale horizontally is just one side of the Big Data story. The other side, namely the ‘alternative data model’-aspect, is equally as important. At first glance, key-value and wide-column data stores may give you the impression that you are still working with fairly typical row-oriented data. Yet, these alternative data models allow you to solve problems in a conceptual very different way. Graph databases for instance, which use the powerful notion of nodes and edges, allow you to model your data and solve your problems in a truly elegant fashion.

I guess what I’m trying to say is that you shouldn’t own millions of data records in order to be eligible to use NoSQL and Big Data technologies. By cleverly applying some of the alternative data models, you can simplify the software architecture of various day to day applications and unlock the full potential of your (maybe limited) data set.

Expect our first blog article to be available by the end of June.