10 - Data and Databases - Spring Data
Introduction
Spring Data’s mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store.
It makes it easy to use data access technologies, relational and non-relational databases, map-reduce frameworks, and cloud-based data services. This is an umbrella project which contains many subprojects that are specific to a given database. The projects are developed by working together with many of the companies and developers that are behind these exciting technologies.
Features:
- Powerful repository and custom object-mapping abstractions
- Dynamic query derivation from repository method names
- Implementation domain base classes providing basic properties
- Support for transparent auditing (created, last changed)
- Possibility to integrate custom repository code
- Easy Spring integration via JavaConfig and custom XML namespaces
- Advanced integration with Spring MVC controllers
- Experimental support for cross-store persistence
Examples of database types
SQL
- Normalized: typed database
- Very Structured: Less error-prone when dealing with its data as it is all very defined
- Low scalability: relational databases introduce high coupling between tables
- Relational database: tables linked by ID fields
- Example: each Java entity has its own table and they can be joined using ID fields
NoSQL
- Not normalized: database isn’t typed (JSON-style entries, documents)
- High scalability
- Fast query responses
- Examples:
- DynamoDB
- MongoDB
Accessing data sources from Spring Boot
Add the appropriate Spring Data dependency to the project and configure the data source properties in the application.properties
or application.yml
file.
Database or store?
A datastore (store) is, as its name implies, a place where data is stored. The simplest example of a store is a flat file saved on your disk.
You can also save data in a database, in which the data is stored physically in files, but those files are managed by some, very often sophisticated, management system.
From this perspective, databases are a special type of datasore.
Not all NoSQL
databases have a built-in “manager”, or their function is very limited, so the management is done in the application level. That is why you may see them just as another storage system. Simply speaking, simple NoSQL
databases (for example, key-value) are very often referred as a store while those more complicated (graphs) as a database, but this is not a rule of thumb.
SQL
We can classify database-management systems according to the database models that they support. First large-scale used models, dominant in the market for more than 20 years, were relational databases, and arose in the 1970s.
SQL stands for Structured Query Language, and these databases where primarily used for writing and querying data. SQL databases uses Edgar F. Codd’s relational model based on tabular data representation.
NoSQL
NoSQL databases, also known as not only SQL, are non-tabular databases and store data differently than relational tables.
NoSQL databases come in a variety of types based on their data model. The main types are document, key-value, wide-column, document-oriented and graph. They provide flexible schemas and scale easily with large amounts of data and high user loads.
Denormalization: the act of copying the same data into multiple documents or tables in order to simplify/optimize query processing, or to fit the user’s data into a particular data model. This collides with the SQL approach, where there are no data duplicates.
SQL vs NoSQL
Comparative table
Concept | SQL | NoSQL |
---|---|---|
Data Model | Relational | Document, key-value, column-family, graph |
Query language | Structured Query Language (SQL) | Query APIs, sometimes proprietary |
Scalability | Vertical | Horizontal |
Data consistency | Strong | Eventual |
Transactional support | ACID compliance | Limited |
Schema definition | Required | Optional |
Query flexibility | Limited | Flexible |
Join operations | Complex | Not supported |
Data modeling | Fixed schema | Dynamic schema |
Availability and Fault tolerance | Low | High |