- 内容提要
- 序
- 前言
- 第一部分 背景知识
- 第 1 章 Spring Data 项目
- 第 2 章 Repository:便利的数据访问层
- 第 3 章 使用 Querydsl 实现类型安全的查询
- 第二部分 关系型数据库
- 第 4 章 JPA Repository
- 第 5 章 借助 Querydsl SQL 实现类型安全的 JDBC 编程
- 第三部分 NoSQL
- 第 6 章 MongoDB: 文档存储
- 第 7 章 Neo4j:图数据库
- 第 8 章 Redis:键/值存储
- 第四部分 快速应用开发
- 第 9 章 使用 Spring Roo 实现持久层
- 第 10 章 REST Repository 导出器
- 第五部分 大数据
- 第 11 章 Spring for Apache Hadoop
- 第 12 章 使用 Hadoop 分析数据
- 第 13 章 使用 Spring Batch 和 Spring Integration 创建大数据管道
- 第六部分 数据网格
- 第 14 章 分布式数据网格:GemFire
- 关于封面
前言
数据访问领域现状概述
数据访问领域在过去的 7 年间发生了重要的变化。过去 30 年间一直占据企业级数据存储和处理核心位置的关系型数据库已经不能再独领风骚了。在过去的 7 年间诞生了很多可选的数据存储形式,当然也有的面临着消亡,它们被使用到了带有关键任务的企业级应用程序之中。这些新的数据存储形式是为了解决特定的数据访问问题而设计的,使用关系型数据库通常无法高效地解决这些问题。
将关系型数据库推到拐点的一个问题就是 扩展性 (scale)。试问,我们如何将几百甚至几千 TB(terabyte)的数据存储到关系型数据库中?这个问题让我想到了一个笑话,病人说:“大夫,我一这样动就疼”而医生则说:“那就别这样动呗!”暂且把笑话放在一边,存储如此巨量数据的推动力是什么呢?在 2001 年,IDC 报告说“人们创造和复制的数据将会超过 1.8ZB(zettabytes),而且每隔两年就会翻番 [1] ”。新的数据涵盖各种类型,如媒体文件、日志文件、传感器数据(RFID、GPD、遥测设备……)、Twitter 上的消息以及 Facebook 上的帖子。尽管对于企业来讲存储于关系型数据库中的数据依然非常重要,但是这些新型的数据并没有存储在关系型数据库之中。
一般用户所关注的需求是存储大量的媒体文件,而企业却发现存储和分析这些新型数据的重要性。在美国,各行各业的公司所存储的数据超过了 100TB,有的公司的数据甚至超过了 1PB(petabyte) [2] 。大家的共识是持续地分析这些数据会为商业上带来明显的收益。例如,如果产品能够自动汇报其状况,那么公司就可以更容易地掌握产品的行为。为了更好地理解客户,公司在决策制定的过程中可以吸收社交媒体的数据。这甚至引起了主流媒体的报道,例如,Orbitz 发现 Mac 用户偏好较为昂贵的酒店( http://on.wsj.com/UhSlNi ),而 Target 会预测其客户家生孩子的时间( http://www.nytimes.com/2012/02/19/magazine/shopping-habits.html ),从而能够在公开的出生记录发布之前给客户邮寄优惠券。
大数据 (Big Data)通常指的是这样一种流程:存储大量的数据、保持其原始格式、持续地进行分析并且会与其他的数据源结合起来提供某个领域更深入的理解,这种领域可能是商业上的也可能是自然科学上的。
很多的公司和科研实验室在大数据这个词流行起来之前就开始这样做了。当前的过程与以往的不同在于,智能的数据分析所带来的价值要高于硬件的成本。现在执行这种类型的分析不再需要购买 4 万美元一颗的 CPU 了;商用的硬件集群中每颗 CPU 的价格是 1000 美元。对于大型的数据集,存储区域网络(Storage Area Network,SAN)以及网络附属存储(Network Attached Storage,NAS)的价格较为昂贵:每 GB(gigabyte)是 1~10 美元,如果复本构建到数据库中而不是硬件之中,那本地磁盘的成本每 GB 只有 0.05 美元。对于商用的硬件集群,使用本地磁盘的数据传输率也要比基于 SAN 或 NAS 的系统更高──对于相同价格的系统,前者能快 500 倍。在软件方面,新的数据访问技术大多数都是开源的。尽管开源并不意味着零成本,但是这显然会降低使用门槛,相对于传统的商业软件,它们能够降低采购的整体成本。
另一个能够区分新型数据存储与关系型数据库的问题域就是关系型的数据模型。如果你想分析上百万人的社交图谱,图形数据库更接近这个领域的模型,使用这种数据库难道不是很自然的事情吗?如果需求持续地要求你修改关系型数据库管理系统(RDBMS)的模式(schema)以及对象关系映射(ORM)层,那该怎么办呢?可能“无模式(schema-less)”的文档数据库能够减少对象映射的复杂度,相对于僵化的关系型模型,它所提供的系统更易于演化。尽管每种不同的数据库各有其独特之处,但是可以基于其数据模型进行大致分类。基本的分类情况如下:
键 / 值
我们所熟悉的数据模型,类似于哈希表(hashtable)。
列族
扩展的键/值数据模型,值的数据类型也可以是键/值对的序列。
文档
半结构化数据的集合,如 XML 或 JSON。
图
基于图论,数据模型中包括节点(node)和边(edge),它们都可以包含属性(property)。
这些新的数据库都可以归类在“NoSQL 数据库”之下。回顾历史,这个名字尽管朗朗上口,但是并不精确,因为它容易让人觉得这些数据库不能进行查询,但事实并不是这样。它的基本含义是摆脱关系型数据模型以及关系型数据库的 ACID 特性(原子性、一致性、隔离性以及持久性)。
要摆脱 ACID 特性的主要驱动力在于,很多的应用程序提高了可扩展写(scaling write)的优先级,并且希望即便系统的某一部分失效,其他部分依然可以继续运作。尽管在关系型数据库中,可以通过在数据库之前使用内存缓存来实现可扩展读,但是进行可扩展写要困难得多。为了标识这类应用程序,通常将其命名为“BASE”系统,在这里缩写代表着基本可用(basically available)、可扩展性(scalable)、最终一致性(eventually consistent)。具有键/值数据模型的分布式数据网格并没有归类到这种新的 NoSQL 数据库之中。然而,它们提供了与 NoSQL 数据库类似的特性,如数据的可扩展性以及组合计算能力和数据的分布式计算功能。
从上面简短的介绍中,你能够了解到数据访问的现状,目前正在发生的是一场革命,关注数据的人会非常兴奋。关系型数据库并没有消亡,在很多企业的运作中它依然是核心,并且会持续很长的时间。但是,趋势很明显:新的数据访问技术解决了关系型数据库所无法解决的问题,因此作为开发人员,我们必须要扩充自己的技能,要能够处理这两种技术。
Spring 框架长期以来都致力于简化 Java 应用程序的开发,尤其是使用 Java 数据库连接(Java Database Connectivity,JDBC)或对象关系映射器编写基于 RDBMS 的数据访问层方面。在本书中,我们力图帮助开发人员使用这些新技术高效地编写 Java 应用程序。Spring Data 项目直接处理这些新的技术,因此你能够将已有的 Spring 知识延伸到它们之中,或者通过使用 Spring Data,也能够更深入地学习 Spring。不过,我们也没有抛弃关系型数据库。Spring Data 为了 Spring 能支持 RDBMS 扩展了新功能。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论