NoSQL, the Cloud, and Java (Part 3): The Standards
Join the DZone community and get the full member experience.Join For Free
The number of NoSQL databases is growing. There are already more than two hundred solutions divided into several categories, and this number has been increasing over time beyond popularity. One solution would be to create a standard API to simplify the use of those databases. After all, the behaviors are basic operations, but after all, what is the reason for not implementing this requirement? This article aims to discuss and update a point of these works related to the standards of NoSQL databases.
Within Info World, the article “The time for NoSQL standards is now” mentions that the critical point for related databases is that relational databases have standards. This pattern in relational databases allows, in addition to avoiding vendor lock-in, creating tools, API in programming languages, among other devices around SQL. If there is a NoSQL standard, the expectation is that the behavior will happen similarly.
“The key advantage of the RDBMS, rather, is standardization. The history of relational databases has proven that even a poor job of standardization can create a market better than none at all. Indeed, standardization is the key obstacle to the takeover by the new breed of databases.” Andrew C. Oliver, Info World.
However, this article is from 2012. There has been no great success—however, a large number of attempts. One of the reasons, as already mentioned, lies in the great diversity of types and the number of vendors making it difficult to synchronize the definition of expected behaviors.
An alternative would be to bring this abstraction instead of the database layer to the API at the software level.
An API-level solution was tried within the Java world within the platform until then called Java EE (currently known as Jakarta EE). In its strategy, it would divide between JPA and JDBC, of which there would be an API for each existing API in addition to specific resources for a particular database.
In the philosophy of dividing and conquering, the best existing initiatives for the standardization process are a single type of API. The best results come, specifically within the graph API. Within this work, two projects can be untied.
OpenCypher focuses on creating a standard API for communicating graph-type banks with Graph Query Language, GQL, ISO for graphs. The database example. There are currently about 21 graphical databases that support GQL. It is based on Neo4J, which is one of the most famous banks. So, if the developer has experience with Neo4J, he would be familiar with this concept.
Another solution is an Apache Tinkerpop project, just like OpenCypher, which is open source. This project is an API whose objective is to be a JDBC for the graph API. It uses an API in several languages, including Java, which has a language gremlin through this API. Currently, there is support for more than thirty API-type databases.
Another option would be Eclipse JNoSQL, which followed a line similar to the project that Oracle would like to deliver in the Java EE 9 until then. Thus, two API layers would be an API for mapping and an API for communication with extensions to support particular database behaviors.
As in Oracle's proposal, in both layers, there is an API for each type. In the Graph API, instead of creating a new API, the Apache Tinkerpop API is used.
Eclipse JNoSQL became the basis for creating the first specification for the Jakarta world as Jakarta NoSQL.
Why Not Use JPA in the NoSQL Database?
There is a massive discussion about that. In summary, it does not make sense to use an API to relational and put it on NoSQL.
The intention is excellent. Once the developer knows the JPA, this person can use the same API to work on NoSQL, decreasing the complexity and learning curve.
Indeed, in Java history, we have this kind of API to covers a variety of databases: the Java Data Object, the JDO: https://www.oracle.com/java/technologies/java-data-objects.html
Unfortunately, this project did not become popular.
In the Jakarta NoSQL there is this at least once in the month:
In summary, we can use Oliver comments:
We've also analyzed another solution on It, such as:
Both did not go further because NoSQL has a considerable difference. Besides, there are a couple of details in the NoSQL world, such as MongoDB has transactions; however, we need to think twice because of the performance issue. Also, there is Cassandra, who does not provide transactions at all, and so on.
Summary: When we a boat API and move it on the plane just because both means of transport tend to be a bad idea.
The advantages to create the use of standards within the NoSQL world are innumerable, for example, a shorter learning curve, ease of creating tools such as testing units, ease of exchanging banks, etc. However, there are several challenges in addition to the incredible diversity; the changes are constant. With that, the work with NoSQL standards growing with several projects. However, no finished projects.
Opinions expressed by DZone contributors are their own.