NoSQL, the Cloud, and Java: Part 1: The NoSQL Approaches
In this first analysis of the Java framework for NoSQL, learn a little about the categories in addition to the trade-offs.
Join the DZone community and get the full member experience.Join For Free
Non-relational databases or NoSQL are increasingly present in solutions in more conservative areas such as financial sectors and health, among others. With the popularization of this solution, the question arises of how to integrate these databases with Java. This post will analyze existing solutions in the Java world and classify them in this integration with NoSQL.
Motivation for NoSQL
A good starting point before talking about non-relational databases is the motivation for using this type of database. It is always important to point out that NoSQL databases' objective is not to compete with the already consolidated relational databases.
In distributed architectures, we will always have to face the CAP theorem. In some cases, it is more plausible, for example, to give up a greater consistency to obtain more prominent availability or fault tolerance. As it is always important to stress, according to the book Fundamentals of Software Architecture: An Engineering Approach, good software architecture is based on dealing with trade-offs. Thus, once opting for a NoSQL database, some already integrated properties into the relational database are lost.
This article will not focus on talking about the challenges of working with distributed databases. However, this excellent book deals with this subject.
There is the possibility of having greater flexibility in the model, such as schemeless or strategies that better adhere to the BASE than ACID makes NoSQL a good option. However, being schemeless does not mean having a database without consistency.
Each vendor characterizes NoSQL with an odd feature, which will make a lot of sense for some businesses, such as a search engine, setting consistency and availability of a request, etc.
A prominent danger is to relate the adoption of NoSQL based on terms such as "scalability" and "speed." Unfortunately, these are words that have just become more sales pitch than a technical solution in itself. If you choose to use this term, understand the reason and in which situations these groups perform better than other competitors. Otherwise, it tends to be a follow the herd effect. The fact is that relational databases are mature, efficient and can handle billions of records as well.
NoSQL does not have any standards. And in general, they are defined according to the structure in which it stores the information. Simply put, we have the five most popular types of NoSQL databases.
Key-value: Very similar to a Map structure
Wide Column/Column Families: A two-dimensional interpretation of the key-value database. From a key, it is possible to have a large number of values.
Document: A structure very similar to a JSON or XML file.
Graph: A database that uses the graph structures so that the queries will be based on the edges, vertex, and the respective properties.
Multi-model: Although many pieces of literature do not consider it a type in itself, after all, it is a database that supports more than one type presented above.
In addition to these types mentioned above, other types are emerging, for example, the time series. The considerable amount of NoSQL database and classes make a NoSQL solution a colossal challenge to the Java world.
Just like NoSQL database concepts, solutions in the Java world have transcendent diversity. The statements are in two points:
Abstraction level: Thinking about an OOP paradigm, it is according to how much the API can absorb the database's complexity.
Plurality: It is defined according to usability or frequency that a single API can be helpful in multiple databases.
API Abstraction Level
An API's abstraction is on how much the solution can absorb or hide the paradigm in the development team's from the database.
As the lowest level of abstraction, we have the Driver: The Driver has a very close relationship with JDBC, however, for NoSQL databases. This type of API will be possible to work with the database structure very close to the variety within the database. It is possible to guarantee greater flexibility in addition to being a lighter solution compared to Mapper. Not to mention that it becomes natural to work with Data-Oriented Programming.
The biggest problem with this solution is if you need to work with OOP. In this case, there is a great deal of conversion between the database structure and the entity. This boilerplate, in addition to requiring more time and more code, this process can result in bugs.
Some examples of Drivers are:
On the other hand, we have an API that makes a gigantic abstraction for the NoSQL solutions: the Mappers: Within the NoSQL world, they also have their derivations similar to ORM, such as OxM OGM, and so on.
Mappers make work and communication much easier since they are responsible for converting the database to the entity. The boilerplate reduction is another central feature of this API since, in addition to decreasing the chance of creating bugs, it increases productivity within the developer team. Depending on the degree of abstraction of this API type, it is possible to forget that there is a database under it.
The mapper has two conversion strategies, either as ActiveRedord that handles the entity behavior and the responsibility for database operations in the API, gaining greater ease and centralizing functions in the API itself. Or Templates classes that are responsible for performing this type of operation.
However, its abstraction has a price. For example, the impedance between the paradigms that also happens in the relational also occurs in NoSQL. The other point is related to the generation of metadata. That through the annotations within the entities, they generate information to perform the conversion, which can be at build time such as the Java Annotation Processor or at execution time through Reflection.
Some examples of Mappers within NoSQL solutions:
It is defined according to the usability or frequency that a single API can be useful in databases. As the communication drivers tend to be specific, this definition is more valid for the mapping layer.
For example, an API supporting more than five databases will have a greater plurality than one that supports a single database.
At the lowest level of plurality, there are specific APIs, that is, an API for the single database. The specific APIs have the most significant advantage of the tendencies to have all the database resources and always to keep updated according to the version of the database. However, for each new database, it is necessary to have an API, resulting in a learning curve.
On the other hand, agnostic APIs allow using a single API to support different types of databases. Its advantage is the possibility of reusing the API in several databases, making it easier for both a smaller learning curve and a big step towards polyglot persistence. However, there are problems with synchronizing database updates and using a single API to bring each database's particular resources.
JPA has undoubtedly impacted the Java world's persistence APIs with millions of documentation, books, publications, and lectures. In general, the developer is already familiar with it in public. Using this API to support NoSQL databases is a good strategy as it reduces the learning curve on the part of the developer team. However, an API focusing on relational databases is not supported and flexible for NoSQL databases. It would be the classic strategy of using a knife in the expectation of behaving like a fork.
Examples of agnostic APIs include:
The JPA based:
That does not use JPA:
To conclude, we made an introduction about NoSQL solutions within the Java world. It starts by explaining the reason and reason for using it or, especially, when not to use it beyond the classifications of these frameworks. The solutions for this type of database are increasingly growing to the point that some solutions platforms will focus on the next post.
Opinions expressed by DZone contributors are their own.