NoSQL Zone is brought to you in partnership with:

Davy Suvee is the founder of Datablend. He is currently working as an IT Lead/Software Architect in the Research and Development division of a large pharmaceutical company. Required to work with big and unstructured scientific data sets, Davy gathered hands-on expertise and insights in the best practices on Big Data and NoSql. Through Datablend, Davy aims at sharing his practical experience within a broader IT environment. Davy is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

The (non-)sense of NoSQL O(R)M frameworks

  • submit to reddit

NoSQL seems to be ready for prime time. Several NoSQL companies, including 10gen (MongoDB), DataStax (Cassandra) and Neo Technology (Neo4J), recently received millions in funding to expand their (commercial) NoSQL offerings. Even Oracle is now entering the already crowded NoSQL-space with its very own key-value NoSQL Database 11g. No doubt that this type of publicity will boost the enterprise adoption of NoSQL technologies.

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.

Published at DZone with permission of Davy Suvee, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Mason Mann replied on Fri, 2011/10/14 - 7:06am

Or you can get your act together and just use an Object Oriented database. If CERN says they scale and perform great, then they do (you'll be hard pressed to find a more demanding customer). And they make any impedance mismatch discussion moot.

Mladen Girazovski replied on Fri, 2011/10/14 - 8:36am

I'm a bit confused here, i thought "ORM" was short for "Object Relational Mapping", if i'm not using a relational database, the mapper shouldn't by called "ORM".

JDO has support for non-RDBMS Datastores (have a look at DataNuclues), JPA is per definition only for RDBMS, so JPA is about ORM.

Google has support on their GAE for a subset of JPA 1 ( the default mapping is done via JDO and the implementation is provided by DataNuclues), so they "abused" JPA for non-RDBMS Mapping.

I can see where you coming from when you say that it is probably a misfit to use an ORM tool for mapping to No-SQL Databases, especially when there is (still) things like JDO around that is naturally a better fit for mapping such a datastore if an layer of abstraction to the concrete implementation is needed.

OTOH, marketing always needs something to convince people to buy their product, "you can use your current knowledge" is imho a big promise, but one that will not hold true imho.

Mark Unknown replied on Fri, 2011/10/14 - 10:12am

First, you can't, by definition, use an ORM with a non-relational datastore. So I guess you mean Object-to-Persistence-Mapping. Hibernate has an Object/Grid Mapper (OGM) which, supposedly, does more than grids or at least plans too. So besides that and Spring, what else is there? Probably some JDO implementation.

I sort of see your point. But I do see the use for something that abstracts the implementation of the type of NoSQL database your are using within the type category (see the Spring Data sub projects). If your object model directly matches your persistence model, then you don't need mapping.

"We have all done our own share of low-level database work and have been exposed to the overal technicalities of a RDBMS". Well that is sort of funny because one thing people complain about ORMs is that it hides the RDBMS and thus many people don't know SQL and RDBMS. LOL.

I too like the "Polyglot Persistence" of Spring. As i have mentioned elsewhere, it actually is more than just RDMBS and Neo4j - Lucene is used by Neo4j and can be used with Hibernate, if you use that for the ORM part.

[Note: looks like I took too long to type this up. See above commenter]

Matthew Adams replied on Fri, 2011/10/14 - 8:50am

Don't assume that all of the persistence APIs out there are object-relational frameworks. Remember Java Data Objects (JDO)? It's perfectly suited to NoSQL datastores. In fact, the JDO reference implementation, DataNucleus (open source under an Apache v2 license), already supports several of them.

JDO was designed from the ground up to be completely independent of the underlying datastore technology. Yes, there are parts of the spec that were added in 2.0 that addressed object-relational mapping specifically, but NoSQL stores are one of the kinds of datastores that JDO is intended for.

Also, JDO is still alive and well. JDO 3.0 was recently released, 3.0.1 is immenent, and 3.1 is currently in progress.

So, if you use JDO as your persistence API of choice and start with a relelational database then want to try a NoSQL store, it's mostly (if not completely) a matter of configuration changes with little to no code changes.


JDO expert group member

Matthew Adams replied on Fri, 2011/10/14 - 8:56am

BTW, unlike most other specifications, the JDO API & TCK are developed in open source at Apache. Additionally, the expert group conducts weekly conference calls in the open -- see email list for announcements & meeting minutes.

The website, which admittedly has been a bit neglected, is at DataNucleus, the RI, is at


Nicolas Bousquet replied on Fri, 2011/10/14 - 11:49am

Well in fact using an ORM, OPM or what ever you might like for NoSQL provide somewhat the same benefits (and problems) as you could expect from mapping a RDBMS to it.

Depending of the database and it's real purpose (graphs, documents, relationnal, key value store...) it will exibit totally different performance and features characteristics.

You think that an a mapping framework might not be suited for a NoSQL database. Well exactly like an ORM might not be suited to a relationnal database.

The impedance mismatch stay here anyway. Key Value store are not object databases, and trying to perform an automatic mapping from an object model to a NoSQL database isn't going to be lighting fast.

The thing is, data doesn't fit naturally in an object model, most of the time. And when it does, the underlying database is an object database. Not an RDBMS, not NoSQL.

You can use a mapping tool to basically abstrat the API specific to your DB, map column names and convert type. That's basically it. If you want a real object mapper (with inheritence and all) you'll face lot of problems.

But the question is why do we have ORM, and now why do we have things like hibernate OGM ? Well because this is a market from the vendor point of view. You want to gain market share, you want your solution to be everywhere. Whereas theses solution provide any real benefit or not, whereas this make sence or not is not really your problem.

Face the Red Hat/Hibernate point of view. You managed to have an important place in the ORM place. You are the leader. Now NoSQL comes and if you don't pay attention, you might loose your dominance.

On the opposite, you can take benefit of your trademark, of how you are well known to add a new product to target this market.

If we just ORM and other as way to abstract API different and map column name, this is okay, if you need database independance. And you can use the what the vendor sell you.

If you trust the vendor that its tool can do everything for everybody, and this in the best way possible, you are really naive.

Tomas Milian replied on Fri, 2011/10/14 - 4:51pm

What about JDO? Seems strange not even being mentioned in this article.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.