In the past years, a lot has happened in database technology, especially with regard to distribution. Traditional relational databases are, however, still the most used choice as of today. Their most significant characteristics are the table-based data schemas and the transactional behavior.
NoSQL (non SQL or not only SQL) database systems provide data in other forms than relational tables. These forms include document stores, key-value stores, column-oriented stores, and graph databases. Most of them compromise consistency in favor of availability, scalability, and network partition tolerance. The idea behind NoSQL not making use of full support of relational table structures, ACID transactions (Atomicity, Consistency, Isolation, Durability), and foreign keys as well as table joins, was to support horizontal scalability. This goes back to the well-known CAP theorem. The CAP theorem (Consistency, Availability, Partition tolerance) claims that it is impossible for distributed datastores to guarantee at most two of the three specified constraints. Since distributed networks do not operate reliably (partition tolerance), systems can basically choose whether they want to guarantee consistency or horizontal scalability. Most NoSQL databases choose scalability over consistency. This fact needs to be considered when choosing a datastore technology.
The reason behind NoSQL systems lays in the shortcomings of relational databases. The biggest issue is that relational databases supporting ACID don't scale well horizontally. Database systems are at the core of the enterprise system, usually accessed by multiple application servers. Data that needs to be updated consistently needs to be synchronized in a central place. This synchronization happens in the technical transaction of the business use case. Database systems that are replicated and should both retain consistency would need to maintain distributed transactions in-between themselves. However, distributed transactions do not scale and arguably do not reliably work in every solution.
Still, relational database systems scale well enough for the majority of enterprise applications. If horizontal scalability becomes an issue so that a centralized database is not an option anymore, one solution is to split up persistence using approaches such as event-driven architectures. We will cover that topic in detail in Chapter 8, Microservices and System Architecture.
NoSQL databases also have some shortcomings, especially with regard to transactional behavior. It highly depends on the business requirements of the application as to whether data needs to be persistent in a transactional approach. Experience shows that in almost all enterprise systems at least some parts of persistence demand reliability; that is, transactions. However, sometimes there are different categories of data. Whereas certain domain models are more crucial and require transactional handling, other data may be recalculated or regenerated; for example, statistics, recommendations, or cached data. For the latter type of data, NoSQL datastores may be a good choice.
At the time of writing, no NoSQL system has emerged as a standard or de facto standard yet. Many of them also vary widely in their concepts and usages. There is also no standard targeting NoSQL included in Java EE 8.
Therefore, accessing NoSQL systems is usually realized using the Java APIs provided by the vendors. These make use of lower level standards such as JDBC or their proprietary APIs.