Spring Data：现代企业Java应用的数据访问解决方案

需积分: 13 11 浏览量更新于2024-07-19 1 收藏 9.37MB PDF 举报

《Spring Data：现代企业Java数据访问指南》是由Mark Pollack、Oliver Gierke、Thomas Risberg、Jon Brisbin 和 Michael Hunger 联合撰写的书籍，专为Java企业应用开发者设计。随着技术的发展，尤其是NoSQL数据库和Hadoop的兴起，传统的关系型数据库解决方案已不再满足所有需求。本书旨在帮助开发者理解和利用Spring框架的数据访问框架，以适应非关系型和关系型数据库，甚至两者结合的情况。 Spring Data的核心价值在于其熟悉且一致的编程模型，这极大地降低了开发者在采用新型数据访问技术时的学习曲线。书中详述了如何通过Spring Data与非关系型数据库无缝集成，如MongoDB或Cassandra，以及如何优化使用Spring Data改进后的JPA（Java Persistence API）和JDBC（Java Database Connectivity）支持，提升基于关系型数据库（RDBMS）的数据访问层开发效率。在当今的企业环境中，尽管关系型数据库仍然占据主导地位，但它们不再是唯一的选择。本书不仅提供了关于如何扩展选项的策略，还展示了如何在保持传统优势的同时，利用Spring Data的灵活性来应对日益复杂的数据存储需求。作者们以其丰富的经验，带领读者深入理解Spring Data的架构、设计模式和最佳实践，包括Repository接口、Querydsl和Spring Data JPA的高级用法。此外，书中的例子和案例研究有助于读者将理论知识转化为实际项目中的代码实现。本书适合那些希望更新技能，跟上现代数据访问趋势的Java开发者，无论是对关系型还是非关系型数据库有需求的团队。无论你是初学者还是经验丰富的开发者，都能从中找到提高工作效率和项目质量的方法。总体而言，《Spring Data：现代企业Java数据访问指南》是一本实用的工具书，对于在企业级应用中有效整合多种数据源，提升开发效率，扩展技术栈的开发者来说，是一份不可或缺的参考资料。

Spring, such as Spring Integration and Spring Batch. The book also provides much

value that goes beyond Spring—for example, the discussions of the repository concept,

the merits of type-safe querying, and why the Java Persistence API (JPA) is not appro-

priate as a general data access solution.

While this is a book about data access rather than working with NoSQL, many of you

will find the NoSQL material most valuable, as it introduces topics and code with which

you are likely to be less familiar. All content is up to the minute, and important topics

include document databases, graph databases, key/value stores, Hadoop, and the

Gemfire data fabric.

We programmers are practical creatures and learn best when we can be hands-on. The

book has a welcome practical bent. Early on, the authors show how to get the sample

code working in the two leading Java integrated development environments (IDEs),

including handy screenshots. They explain requirements around database drivers and

basic database setup. I applaud their choice of hosting the sample code on GitHub,

making it universally accessible and browsable. Given the many topics the book covers,

the well-designed examples help greatly to tie things together.

The emphasis on practical development is also evident in the chapter on Spring Roo,

the rapid application development (RAD) solution from the Spring team. Most Roo

users are familiar with how Roo can be used with a traditional JPA architecture; the

authors show how Roo’s productivity can be extended beyond relational databases.

When you’ve finished this book, you will have a deeper understanding of why modern

data access is becoming more specialized and fragmented, the major categories of

NoSQL data stores, how Spring Data can help Java developers operate effectively in

this new environment, and where to look for deeper information on individual topics

in which you are particularly interested. Most important, you’ll have a great start to

your own exploration in code!

—Rod Johnson

Creator, Spring Framework

xiv | Foreword

Preface

Overview of the New Data Access Landscape

The data access landscape over the past seven or so years has changed dramatically.

Relational databases, the heart of storing and processing data in the enterprise for over

30 years, are no longer the only game in town. The past seven years have seen the birth

—and in some cases the death—of many alternative data stores that are being used in

mission-critical enterprise applications. These new data stores have been designed

specifically to solve data access problems that relational database can’t handle as

effectively.

An example of a problem that pushes traditional relational databases to the breaking

point is scale. How do you store hundreds or thousands of terabytes (TB) in a relational

database? The answer reminds us of the old joke where the patient says, “Doctor, it

hurts when I do this,” and the doctor says, “Then don’t do that!” Jokes aside, what is

driving the need to store this much data? In 2001, IDC reported that “the amount of

information created and replicated will surpass 1.8 zettabytes and more than double

every two years.”

New data types range from media files to logfiles to sensor data

(RFID, GPS, telemetry...) to tweets on Twitter and posts on Facebook. While data that

is stored in relational databases is still crucial to the enterprise, these new types of data

are not being stored in relational databases.

While general consumer demands drive the need to store large amounts of media files,

enterprises are finding it important to store and analyze many of these new sources of

data. In the United States, companies in all sectors have at least 100 TBs of stored data

and many have more than 1 petabyte (PB).

The general consensus is that there are

significant bottom-line benefits for businesses to continually analyze this data. For ex-

ample, companies can better understand the behavior of their products if the

products themselves are sending “phone home” messages about their health. To better

understand their customers, companies can incorporate social media data into their

decision-making processes. This has led to some interesting mainstream media

1. IDC; Extracting Value from Chaos. 2011.

2. IDC; US Bureau of Labor Statistics

reports—for example, on why Orbitz shows more expensive hotel options to Mac

users and how Target can predict when one of its customers will soon give birth, al-

lowing the company to mail coupon books to the customer’s home before public birth

records are available.

Big data generally refers to the process in which large quantities of data are stored, kept

in raw form, and continually analyzed and combined with other data sources to provide

a deeper understanding of a particular domain, be it commercial or scientific in nature.

Many companies and scientific laboratories had been performing this process before

the term big data came into fashion. What makes the current process different from

before is that the value derived from the intelligence of data analytics is higher than the

hardware costs. It is no longer necessary to buy a 40K per CPU box to perform this type

of data analysis; clusters of commodity hardware now cost $1k per CPU. For large

datasets, the cost of storage area network (SAN) or network area storage (NAS) be-

comes prohibitive: $1 to $10 per gigabyte, while local disk costs only $0.05 per gigabyte

with replication built into the database instead of the hardware. Aggregate data transfer

rates for clusters of commodity hardware that use local disk are also significantly higher

than SAN- or NAS-based systems—500 times faster for similarly priced systems. On

the software side, the majority of the new data access technologies are open source.

While open source does not mean zero cost, it certainly lowers the barrier for entry and

overall cost of ownership versus the traditional commercial software offerings in this

space.

Another problem area that new data stores have identified with relational databases is

the relational data model. If you are interested in analyzing the social graph of millions

of people, doesn’t it sound quite natural to consider using a graph database so that the

implementation more closely models the domain? What if requirements are continually

driving you to change your relational database management system (RDBMS) schema

and object-relational mapping (ORM) layer? Perhaps a “schema-less” document data-

base will reduce the object mapping complexity and provide a more easily evolvable

system as compared to the more rigid relational model. While each of the new databases

is unique in its own way, you can provide a rough taxonomy across most of them based

on their data models. The basic camps they fall into are:

Key/value

A familiar data model, much like a hashtable.

Column family

An extended key/value data model in which the value data type can also be a se-

quence of key/value pairs.

Document

Collections that contain semistructured data, such as XML or JSON.

Graph

Based on graph theory. The data model has nodes and edges, each of which may

have properties.

xvi | Preface

The general name under which these new databases have become grouped is “NoSQL

databases.” In retrospect, this name, while catchy, isn’t very accurate because it seems

to imply that you can’t query the database, which isn’t true. It reflects the basic shift

away from the relational data model as well as a general shift away from ACID (atom-

icity, consistency, isolation, durability) characteristics of relational databases.

One of the driving factors for the shift away from ACID characteristics is the emergence

of applications that place a higher priority on scaling writes and having a partially

functioning system even when parts of the system have failed. While scaling reads in a

relational database can be achieved through the use of in-memory caches that front the

database, scaling writes is much harder. To put a label on it, these new applications

favor a system that has so-called “BASE” semantics, where the acronym represents

basically available, scalable, eventually consistent. Distributed data grids with a key/

value data model generally have not been grouped into this new wave of NoSQL da-

tabases. However, they offer similar features to NoSQL databases in terms of the scale

of data they can handle as well as distributed computation features that colocate com-

puting power and data.

As you can see from this brief introduction to the new data access landscape, there is

a revolution taking place, which for data geeks is quite exciting. Relational databases

are not dead; they are still central to the operation of many enterprises and will remain

so for quite some time. The trends, though, are very clear: new data access technologies

are solving problems that traditional relational databases can’t, so we need to broaden

our skill set as developers and have a foot in both camps.

The Spring Framework has a long history of simplifying the development of Java ap-

plications, in particular for writing RDBMS-based data access layers that use Java

database connectivity (JDBC) or object-relational mappers. In this book we aim to help

developers get a handle on how to effectively develop Java applications across a wide

range of these new technologies. The Spring Data project directly addresses these new

technologies so that you can extend your existing knowledge of Spring to them, or

perhaps learn more about Spring as a byproduct of using Spring Data. However, it

doesn’t leave the relational database behind. Spring Data also provides an extensive set

of new features to Spring’s RDBMS support.

How to Read This Book

This book is intended to give you a hands-on introduction to the Spring Data project,

whose core mission is to enable Java developers to use state-of-the-art data processing

and manipulation tools but also use traditional databases in a state-of-the-art manner.

We’ll start by introducing you to the project, outlining the primary motivation of

SpringSource and the team. We’ll also describe the domain model of the sample

projects that accommodate each of the later chapters, as well as how to access and set

up the code (Chapter 1).

Preface | xvii

We’ll then discuss the general concepts of Spring Data repositories, as they are a com-

mon theme across the various store-specific parts of the project (Chapter 2). The same

applies to Querydsl, which is discussed in general in Chapter 3. These two chapters

provide a solid foundation to explore the store specific integration of the repository

abstraction and advanced query functionality.

To start Java developers in well-known terrain, we’ll then spend some time on tradi-

tional persistence technologies like JPA (Chapter 4) and JDBC (Chapter 5). Those

chapters outline what features the Spring Data modules add on top of the already ex-

isting JPA and JDBC support provided by Spring.

After we’ve finished that, we introduce some of the NoSQL stores supported by the

Spring Data project: MongoDB as an example of a document database (Chapter 6),

Neo4j as an example of a graph database (Chapter 7), and Redis as an example of a

key/value store (Chapter 8). HBase, a column family database, is covered in a later

chapter (Chapter 12). These chapters outline mapping domain classes onto the store-

specific data structures, interacting easily with the store through the provided appli-

cation programming interface (API), and using the repository abstraction.

We’ll then introduce you to the Spring Data REST exporter (Chapter 10) as well as the

Spring Roo integration (Chapter 9). Both projects build on the repository abstraction

and allow you to easily export Spring Data−managed entities to the Web, either as a

representational state transfer (REST) web service or as backing to a Spring Roo−built

web application.

The book next takes a tour into the world of big data—Hadoop and Spring for Apache

Hadoop in particular. It will introduce you to using cases implemented with Hadoop

and show how the Spring Data module eases working with Hadoop significantly

(Chapter 11). This leads into a more complex example of building a big data pipeline

using Spring Batch and Spring Integration—projects that come nicely into play in big

data processing scenarios (Chapter 12 and Chapter 13).

The final chapter discusses the Spring Data support for Gemfire, a distributed data grid

solution (Chapter 14).

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements

such as variable or function names, databases, data types, environment variables,

statements, and keywords.

xviii | Preface

www.allitebooks.com

剩余313页未读，继续阅读

K.Sun

粉丝: 180
资源: 6

Spring Data：现代企业Java应用的数据访问解决方案

spring-data Jpa Jar包

spring Data 整合jar

spring-data-redis-1.7.2.RELEASE.jar

spring data自动装配

springdatajpa依赖

spring data elasticsearch

springboot + springdata

spring data是什么

spring data 的課程

spring data jpa面试题

最新资源