SQLifying NoSQL – Are ORM tools relevant to NoSQL?

Introduction

If you reached this page, it’s fair to assume that you must have worked on at least one relational database in your lifetime. They have been in use for a quarter of a century and are found in almost all business applications.

But, NoSQL databases are gaining traction these days. they are often called “Not only SQL” databases. It’s an umbrella term for a loosely defined class of non-relational data-stores.

They exhibit following main characteristics:

• They don’t use SQL as their query language.
• They may not give full ACID guarantees.
• They have distributed, fault-tolerant architecture.

In this article, I am going to explore whether ORM tools (whatever they are) make sense in NoSQL world…and whether they will be able to solve problems that are NoSQL specific. Next we’ll delve into approaches and challenges in making such a tool. This article assumes you are already familiar with and have worked on one (and possibly more) NoSQL database.

ORM Solutions

ORM (Object Relational Mapping) solutions came into existence to solve OO-impedance mismatching problem. Most popular among them are Hibernate, Toplink, EclipseLink etc. They worked beautifully with relational databases like Oracle and MySQL, among others.

Each ORM solution had its own API and object query language (like HQL for hibernate) which made it difficult for programmers to switch from one framework to another. As a result, efforts were made to make standards and specifications.

 Most popular ORM Standards are:

• EJB – Enterprise Java Beans (Entity Beans to be specific)
• JPA – Java Persistence API
• JDO – Java Data Objects
• SDO – Service Data Objects

 

Problems in working with NoSQL

Problem with NoSQL databases is that there is NOT EVEN ONE existing industry standard (like SQL) for them. The very basic idea of “something opposed to SQL”…and as a result – deviation from standards and rules, is going to be suicidal, if not corrected at right time. Learning to work with a new NoSQL database is always cumbersome as a result.

Apart from that, people lack in-depth knowledge of NoSQL. Even if they do, they are confined to one or two. In relational world, people depend upon their knowledge of SQL and JDBC to work on basic and intermediate database things. Switching to another database requires little or almost no effort, which otherwise is painful in NoSQL world.

ORM for NoSQL?

ORM for NoSQL is a bit mis-leading term. People prefer to call it “OM tool for NoSQL” or maybe “ODM – Object data-store Mapping tool”. ORM frameworks have already been there for 30+ years and it’s a de-facto industry standard. People are very clear about what ORM tools are supposed to do. There are no surprises.

Key here is to let people forget worrying about complexities inherent in NoSQLs. Let them do things in a way they already know and are comfortable with. Why not use an approach that is there for this problem domain for decades and has proven its usefulness.

A good use case advocating use of ORM tools is migration of applications (built using ORM tool) from RDBMS to NoSQL database. (or even from one NoSQL database to another). This requires (at least in theory) little or no programming effort in business domain.

Challenges in Making ORM Solution

Here are some real challenges that ORM solution providers are going to face:

• Making one solution for many common-looking problems requires some really tough generalizations and abstractions. Design is going to be a challenge as abstractions sometimes snatch away (or at least makes it difficult to put in front) many powers of NoSQL.
• NoSQL databases are built for performance and scalability. ORM tools have to employ techniques that don’t put too much burden on performance which users would otherwise get while using plain vanilla driver available with the database.
• Many ORM standards (like JPA and JDO) were written for relational databases that don’t always provide ways of doing certain things in NoSQL. In fact, most of the ORM tools (like hibernate) were built to solve only 80% of the frequently used mapping problems. Low level tweaking may prove to be crucial for applications built on NoSQL databases. Challenge here is to provide developers hooks for solving remaining 20% of the mapping problem.
• Each NoSQL database has its own architecture and network topology. They make specific assumptions in data center, racks and disks connectivity and how data is stored and distributed on them. In simple terms – NoSQL databases are “born distributed”. It’s a real challenge to provide all these configuration using ORM specifications.

Approach

There are some guidelines worth sharing, that helps develop ORM tools for NoSQL:

• Map notations in ORM framework to structures in NoSQL that they are most likely to be thought related to. Example is @Embedded in JPA with Super column in Cassandra.
• If framework provides a way to operate on database directly, leverage them. Example is mapping Native queries in JPA with CQL in Cassandra.
• NoSQL is built for performance. noticeable overhead over plain drivers is going to be a big turn-off for users. Make special efforts to keep overhead of ORM to minimum even if that requires sleepless nights and weeks of design-discussion fights.

Other Benefits

There are many other benefits of using a standard ORM tool over plain low-level driver library:

• Ease of use, faster development, increased productivity.
• NoSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene.
• ORM solutions (like Kundera and SpringData) may provide polyglot persistence transparently that would otherwise be impossible. This may prove to be a boon for complex application requiring storage in multiple databases.
• Most NoSQL databases lack transaction management capabilities as they were not built that way (and because they were built to solve problem that didn’t require it at the first place). Many ORM specifications (like JPA) mandate this capability. If by any chance your application requires likes of atomicity, they are going to be your rescuer.

As it happens with everything in life, Discipline and Rules that you promise to yourself, pay in the longer run…Those NoSQLs that provide best of balance in features and ease of use are going to be successful eventually. ORM tools could be one facilitator in that pursuit.

[author]

Hi, I am Amresh. I work for R&D lab of Software Product Engineering firm Impetus Technologies.

I am technology enthusiast and love reading…mostly news and magazine articles. I am a fitness freak and love watching movies and listening to music. My Blog

[/author]