NOSQL, JPA and Persistence of Generic Graph

NOSQL revives an old debate

Rapidly growing NOSQL Movement has revived an old technical debate on scope and applicability of relational database for a class of applications. Mainly stemming from the demands of web-scale applications such as eBay, LinkedIn, FaceBook or Google -- the proponents of these growing movement are exploring next generation of non-relational databases and a non-ACID transaction model that has remained the mainstay of relational databases for several decades. A host of alternative persistent storage Dynamo, BigTable, Cassandra, HBase and many others have already been operational in highly demanding production environments. These non-relational storage systems are designed to be horizontally scalable with distributed partitions, replicated for high availability and often as a schema-free key-value store. Of course, nothing comes free. The gainful characteristics of non-relational databases often come at the cost of lowering consistency warranty (the C in ACID) (redefining it as BASE in the process) or limiting the queries only on their keys and not on attributes/relations of data available that are basic capabilities of any relational database.

 

JPA is no SQL too

Java Persistence API (JPA) is also is a rapidly growing technology, through may not be as popular as NOSQL. Like NOSQL, JPA also grew out of a limitation of relation databases albeit of a different kind. This limitation, commonly known as object-relational impedance mismatch, refers to the problem of representing an object-oriented model to a relational database schema. The common concepts of object models in Java language such as how multi-cardinality relations are expressed as collections or how separate references must be used for bi-directional relationship significantly differ from the equivalent metaphors that express relations in a relational database. JPA solution to this problem was to map the object model to a relational schema. JPA promotes a programming model where the application developer expresses the business logic entirely on a purely object-oriented model while the JPA provider automatically maps these operation to appropriate SQL required to insert, update or query the relational database. Hence, an application developer using JPA does not have to write a single line of SQL either. This different kind of "no SQL" feature of JPA, however, often generates a certain degree of unease among the developers on loss of control of their familiar and beloved SQL. In fact, JPA does provide ability to use SQL directly or ancillary facilities for intercepting the generated SQL for the application developer. The major power of JPA comes from the fact that JPA retains the entire power of ACID transaction model and powerful query capability offered by the underlying relational database systems. But unlike schema-free NOSQL usage scenario where arbitrary data structures can be persisted, JPA requires a strongly-typed a priori Java object model be mapped to relational database schema. On the other side of the coin, JPA only works with a single relational database. JPA neither defines a methodology to work with distributed partitions nor with a persistent storage system that does not talk SQL.

 

JPA Perspective on NOSQL

Given this partial overlap of purpose between NOSQL and JPA and their respective differences, the question I asked the following:

• how can JPA work with a more flexible, dynamic data model than strongly-typed POJO on a relational database?
• how can JPA work with new generation of NOSQL databases?

In future installments, I will elaborate on these questions based on some concrete examples.