大数据挑战与NoSQL数据库技术

　　《大数据挑战与NoSQL数据库技术》从理论、系统、应用三个方面详细讲述了大数据的技术知识，并针对NoSQL数据库技术做了深入的分享，是学习大数据技术的地图、指南手册。帮助读者跳出迷局，厘清思路，系统地做好相关知识储备，拥抱大数据时代！

　　《大数据挑战与NoSQL数据库技术》共分为三部分。理论篇重点介绍大数据时代下数据处理的基本理论及相关处理技术，并引入NoSQL数据库；系统篇主要介绍了各种类型NoSQL数据库的基本知识；应用篇对国内外几家知名公司在利用NoSQL数据库处理海量数据方面的实践做了阐述。
　　《大数据挑战与NoSQL数据库技术》对大数据时代面临的挑战，以及NoSQL数据库的基本知识做了清晰的阐述，有助于读者整理思路，了解需求，并更有针对性、有选择地深入学习相关知识。

　　陆嘉恒，中国人民大学教授，博士生导师。2006年毕业于新加坡国立大学计算机科学系，获博士学位；2006-2008年在美国加利福尼亚大学尔湾分校（University of California， Irvine）进行博士后研究；2008年加入中国人民大学，2012年破格晋升为教授。主要研究领域包括数据库技术和云计算技术。先后在SIGMOD、VLDB、ICDE、WWW等国际重要会议和期刊上发表数据库方向的论文40多篇，主编多本云计算和大数据的教材和著作。

第1章 概论
1.1 引子
1.2 大数据挑战
1.3 大数据的存储和管理
1.3.1 并行数据库
1.3.2 NoSQL数据管理系统
1.3.3 NewSQL数据管理系统
1.3.4 云数据管理
1.4 大数据的处理和分析
1.5 小结
参考文献
理 论 篇
第2章 数据一致性理论
2.1 CAP理论
2.2 数据一致性模型
2.3 ACID与BASE
2.4 数据一致性实现技术
2.4.1 Quorum系统NRW策略
2.4.2 两阶段提交协议
2.4.3 时间戳策略
2.4.4 Paxos
2.4.5 向量时钟
2.5 小结
参考文献
第3章 数据存储模型
3.1 总论
3.2 键值存储
3.2.1 Redis
3.2.2 Dynamo
3.3 列式存储
3.3.1 Bigtable
3.3.2 Cassandra与HBase
3.4 文档存储
3.4.1 MongoDB
3.4.2 CouchDB
3.5 图形存储
3.5.1 Neo4j
3.5.2 GraphDB
3.6 本章小结
参考文献
第4章 数据分区与放置策略
4.1 分区的意义
4.1.1 为什么要分区
4.1.2 分区的优点
4.2 范围分区
4.3 列表分区
4.4 哈希分区
4.5 三种分区的比较
4.6 放置策略
4.6.1 一致性哈希算法
4.6.2 容错性与可扩展性分析
4.6.3 虚拟节点
4.7 小结
参考文献
第5章 海量数据处理方法
5.1 MapReduce简介
5.2 MapReduce数据流
5.3 MapReduce数据处理
5.3.1 提交作业
5.3.2 初始化作业
5.3.3 分配任务
5.3.4 执行任务
5.3.5 更新任务执行进度和状态
5.3.6 完成作业
5.4 Dryad简介
5.4.1 DFS Cosmos介绍
5.4.2 Dryad执行引擎
5.4.3 DryadLINQ解释引擎
5.4.4 DryadLINQ编程
5.5 Dryad数据处理步骤
5.6 MapReduce vs Dryad
5.7 小结
参考文献
第6章 数据复制与容错技术
6.1 海量数据复制的作用和代价
6.2 海量数据复制的策略
6.2.1 Dynamo的数据库复制策略
6.2.2 CouchDB的复制策略
6.2.3 PNUTS的复制策略
6.3 海量数据的故障发现与处理
6.3.1 Dynamo的数据库的故障发现与处理
6.3.2 CouchDB的故障发现与处理
6.3.3 PNUTS的故障发现与处理
6.4 小结
参考文献
第7章 数据压缩技术
7.1 数据压缩原理
7.1.1 数据压缩的定义
7.1.2 数据为什么可以压缩
7.1.3 数据压缩分类
7.2 传统压缩技术[1]
7.2.1 霍夫曼编码
7.2.2 LZ77算法
7.3 海量数据带来的3V挑战
7.4 Oracle混合列压缩
7.4.1 仓库压缩
7.4.2 存档压缩
7.5 Google数据压缩技术
7.5.1 寻找长的重复串
7.5.2 压缩算法
7.6 Hadoop压缩技术
7.6.1 LZO简介
7.6.2 LZO原理[5]
7.7 小结
参考文献
第8章 缓存技术
8.1 分布式缓存简介
8.1.1 分布式缓存的产生
8.1.2 分布式缓存的应用
8.1.3 分布式缓存的性能
8.1.4 衡量可用性的标准
8.2 分布式缓存的内部机制
8.2.1 生命期机制
8.2.2 一致性机制
8.2.3 直读与直写机制
8.2.4 查询机制
8.2.5 事件触发机制
8.3 分布式缓存的拓扑结构
8.3.1 复制式拓扑
8.3.2 分割式拓扑
8.3.3 客户端缓存拓扑
8.4 小结
参考文献
系 统 篇
第9章 key-value数据库
9.1 key-value模型综述
9.2 Redis
9.2.1 Redis概述
9.2.2 Redis下载与安装
9.2.3 Redis入门操作
9.2.4 Redis在业内的应用
9.3 Voldemort
9.3.1 Voldemort概述
9.3.2 Voldemort下载与安装
9.3.3 Voldemort配置
9.3.4 Voldemort开发介绍[3]
9.4 小结
参考文献
第10章 Column-Oriented数据库
10.1 Column-Oriented数据库简介
10.2 Bigtable数据库
10.2.1 Bigtable数据库简介
10.2.2 Bigtable数据模型
10.2.3 Bigtable基础架构
10.3 Hypertable数据库
10.3.1 Hypertable简介
10.3.2 Hypertable安装
10.3.3 Hypertable架构
10.3.4 基本概念和原理
10.3.5 Hypertable的查询
10.4 Cassandra数据库
10.4.1 Cassandra简介
10.4.2 Cassandra配置
10.4.3 Cassandra数据库的连接
10.4.4 Cassandra集群机制
10.4.5 Cassandra的读/写机制
10.5 小结
参考文献
第11章 文档数据库
11.1 文档数据库简介
11.2 CouchDB数据库
11.2.1 CouchDB简介
11.2.2 CouchDB安装
11.2.3 CouchDB入门
11.2.4 CouchDB查询
11.2.5 CouchDB的存储结构
11.2.6 SQL和CouchDB
11.2.7 分布式环境中的CouchDB
11.3 MongoDB数据库
11.3.1 MongoDB简介
11.3.2 MongoDB的安装
11.3.3 MongoDB入门
11.3.4 MongoDB索引
11.3.5 SQL与MongoDB
11.3.6 MapReduce与MongoDB
11.3.7 MongoDB与CouchDB对比
11.4 小结
参考文献
第12章 图存数据库
12.1 图存数据库的由来及基本概念
12.1.1 图存数据库的由来
12.1.2 图存数据库的基本概念
12.2 Neo4j图存数据库
12.2.1 Neo4j简介
12.2.2 Neo4j使用教程
12.2.3 分布式Neo4j--Neo4j HA
12.2.4 Neo4j工作机制及优缺点浅析
12.3 GraphDB
12.3.1 GraphDB简介
12.3.2 GraphDB的整体架构
12.3.3 GraphDB的数据模型
12.3.4 GraphDB的安装
12.3.5 GraphDB的使用
12.4 OrientDB
12.4.1 背景
12.4.2 OrientDB是什么
12.4.3 OrientDB的原理及相关技术
12.4.4 Windows下OrientDB的安装与使用
12.4.5 相关Web应用
12.5 三种图存数据库的比较
12.5.1 特征矩阵
12.5.2 分布式模式及应用比较
12.6 小结
参考文献
第13章 基于Hadoop的数据管理系统
13.1 Hadoop简介
13.2 HBase
13.2.1 HBase体系结构
13.2.2 HBase数据模型
13.2.3 HBase的安装和使用
13.2.4 HBase与RDBMS
13.3 Pig
13.3.1 Pigr的安装和使用
13.3.2 Pig Latin语言
13.3.3 Pig实例
13.4 Hive
13.4.1 Hive的数据存储
13.4.2 Hive的元数据存储
13.4.3 安装Hive
13.4.4 HiveQL简介
13.4.5 Hive的网络接口（WebUI）
13.4.6 Hive的JDBC接口
13.5 小结
参考文献
第14章 NewSQL数据库
14.1 NewSQL数据库简介
14.2 MySQL Cluster
14.2.1 概述
14.2.2 MySQL Cluster的层次结构
14.2.3 MySQL Cluster的优势和应用
14.2.4 海量数据处理中的sharding技术
14.2.5 单机环境下MySQL Cluster的安装
14.2.6 MySQL Cluster的分布式安装与配置指导
14.3 VoltDB
14.3.1 传统关系数据库与VoltDB
14.3.2 VoltDB的安装与配置
14.3.3 VoltDB组件
14.3.4 Hello World
14.3.5 使用Generate脚本
14.3.6 Eclipse集成开发
14.4 小结
参考文献
第15章 分布式缓存系统
15.1 Memcached缓存技术
15.1.1 背景介绍
15.1.2 Memcached缓存技术的特点
15.1.3 Memcached安装[3]
15.1.4 Memcached中的数据操作
15.1.5 Memcached的使用
15.2 Microsoft Velocity分布式缓存系统
15.2.1 Microsoft Velocity简介
15.2.2 数据分类
15.2.3 Velocity核心概念
15.2.4 Velocity安装
15.2.5 一个简单的Velocity客户端应用
15.2.6 扩展型和可用性
15.3 小结
参考文献
应 用 篇
第16章 企业应用
16.1 Instagram
16.1.1 Instagram如何应对数据的急剧增长
16.1.2 Instagram的数据分片策略
16.2 Facebook对Hadoop以及HBase的应用
16.2.1 工作负载类型
16.2.2 为什么采用Apache Hadoop和HBase
16.2.3 实时HDFS
16.2.4 Hadoop HBase的实现
16.3 淘宝大数据解决之道
16.3.1 淘宝数据分析
16.3.2 淘宝大数据挑战
16.3.3 淘宝OceanBase数据库
16.3.4 淘宝将来的工作
16.4 小结
参考文献

　　1.2 大数据挑战
　　什么是大数据？多大的数据量可以称为大数据？不同的年代有不同的答案[2]。20世纪80年代早期，大数据指的是数据量大到需要存储在数千万个磁带中的数据；20世纪90年代，大数据指的是数据量超过单个台式机存储能力的数据；如今，大数据指的是那些关系型数据库难以存储、单机数据分析统计工具无法处理的数据，这些数据需要存放在拥有数千万台机器的大规模并行系统上。大数据出现在日常生活和科学研究的各个领域，数据的持续增长使人们不得不重新考虑数据的存储和管理。
　　随着社会计算的兴起，人们习惯于在网上分享和交流信息。比如，社交网站Facebook拥有庞大的用户群，而且在不断增长。这些用户每天发出的日志以及分享的资料更是不计其数，其数据量已经达到PB级别，传统的解决方案已经不能很好地处理这些数据。Facebook自己开发了Cassandra系统，现在又采用HBase，这些针对海量数据的管理系统能够较好地为用户提供服务，而且具有可扩展性和容错性，这是解决大数据问题所需要的性能。微博服务商Twitter也面临大数据的挑战，消息的发送量达到每天数亿条，而查询量则达到每天数十亿次，这要求存储管理系统不仅能够存储大规模数据，而且能够提供高吞吐的读/写服务。Twitter原先使用MySQL数据库，之后由于用户暴增便将数据迁移到NoSQL系统上，尽管NoSQL系统还未成熟，但却是解决海量数据的较为有效的方案。其他的互联网公司同样面临着大数据带来的问题，如Goolge搜索引擎需要处理大规模的网页信息，YouTube则需要存储和提供用户分享的视频数据，维基百科提交用户分享的知识等，这些都涉及大规模数据信息存储与管理。
　　随着电子商务的发展，越来越多的人在网上选购商品，商务网站需要存储大量的商品信息和用户的交易信息，涉及大规模的数据。同时网站需要提供迅速的请求响应，以提高用户体验来吸引客户。而且网站还要对这些海量数据进行处理和分析，以便更有针对性地向用户推荐商品，海量数据成为系统构建和业务成败的关键因素。中国商业网站淘宝使用HBase来存储数据，同时不断探索自己的解决之路，开发了支持大数据的数据库系统OceanBase来实现部分在线应用。全球最大的线上拍卖和购物网站eBay也积极寻求海量数据的解决方案，其基于Hadoop建立了自己的集群系统Athena来处理大规模数据，同时开发了自己的开源云平台项目Turmeric来更好地开发和管理各种服务。同时，各大零售公司无论是在线销售还是实体销售，都会注意收集客户的消费信息以便有针对性地提供服务或推荐商品，这些都涉及大规模数据的应用。
　　各个领域的科学研究同样面临海量数据的挑战，从生物基因到天文气象，从物理实验到临床医学，得益于测量技术和设备的发展，这些领域在实验或实践中产生了大量的数据，而人们需要对这些数据进行处理分析从而挖掘出有价值的信息，但这不是容易的事情。随着下一代基因测序技术的发展，基因中所蕴含的信息逐渐被人们所发掘，人们获得更多更准确的基因数据，但是如何匹配基因数据，如何从这些数据中挖掘出所需要的信息，这是生物信息学遇到的新挑战。在环境气象研究中，科学家已经收集了数十年甚至上百年的气象环境数据，在这些数据中分析气候的变化需要海量数据处理技术的支持。在医学药物研究中搜集的大量的病人生理数据和药物测试数据，这些数据的规模很大，需要从中分析出有用的信息。在人文社会科学中，社会学家开始注意互联网社交网络上的人际交往和社会关系，其涉及的数据量也是非常巨大的，从海量数据中找出社会学家感兴趣的内容是富有挑战性的。人工智能研究方面，人们希望计算机拥有人类的学习能力和逻辑推理能力，这就需要机器存储大量的经验数据和知识数据，还需要从这些大量数据中迅速获得所需要的内容，并对其进行分析处理，从而做出正确有效的判断。
　　如今传感器的广泛使用，数据采集更加方便，这些传感器会连续地产生数据，如实时监控系统、网络流量监测等。除了传感器源源不断地产生数据外，许多领域都会涉及流数据，如经济金融领域中股票价格和交易数据、零售业中的交易数据、通信领域中的数据等都是流数据，这些数据最大的特点就是海量，因为它们每时每刻连续不断地产生，但与其他的海量数据不同，流数据连续有序、变化迅速，而且对处理分析的响应度要求较高，因此对于流数据的处理和挖掘往往采用不同的方法。经济金融领域各个方面都产生海量数据，如证券价格变化和股票交易形成的流数据，企业或个人各种经济活动而产生的数据等。现代经济已经步入海量数据时代，在新时代下可以带来创新和生产率增长，并可能出现新的商业模式。利用好经济生活产生的海量数据，可以发挥重要的经济作用，不仅有利于企业的商业活动，也有利于国民经济，提高国家的竞争力。面对大规模的经济数据，人们除了需要提高获取、存储和分析数据的能力，同时需要保障数据的安全和隐私，但这仍然是巨大的挑战。
　　传统的关系型数据库并不能够很好地解决海量数据带来的问题，单机的统计和可视化工具也变得力不从心。一些新的数据管理系统如并行数据库、网格数据库、分布式数据库、云平台、可扩展数据库等孕育而生，它们为解决海量数据提供了多种选择。
　　1.3 大数据的存储和管理
　　任何机器都会有物理上的限制：内存容量、硬盘容量、处理器速度等等，我们需要在这些硬件的限制和性能之间做出取舍，比如内存的读取速度比硬盘快得多，因此内存数据库比硬盘数据库性能好，但是内存为2GB的机器不可能将大小为100GB的数据全部放入内存中，也许内存大小为128GB的机器能够做到，但是数据增加到200GB时就无能为力了。
　　数据不断增长造成单机系统性能不断下降，即使不断提升硬件配置也难以跟上数据的增长速度。然而，当今主流的计算机硬件比较便宜而且可以扩展，现在购置八台8内核、128GB内存的机器比购置一台64内核、TB级别内存的服务器划算得多，而且还可以增加或减少机器来应对将来的变化。这种分布式架构策略对于海量数据来说是比较适合的，因此，许多海量数据系统选择将数据放在多个机器中，但也带来了许多单机系统不曾有的问题。
　　下面我们介绍大数据存储和管理发展过程中出现的四类大数据存储和管理数据库系统。
　　1.3.1 并行数据库
　　并行数据库[1]是指那些在无共享的体系结构中进行数据操作的数据库系统。这些系统大部分采用了关系数据模型并且支持SQL语句查询，但为了能够并行执行SQL的查询操作，系统中采用了两个关键技术：关系表的水平划分和SQL查询的分区执行。
　　水平划分的主要思想就是根据某种策略将关系表中的元组分布到集群中的不同节点上，这些节点上的表结构是一样的，这样就可以对元组并行处理。现有的分区策略有哈希分区、范围分区、循环分区等。例如，哈希分区策略是将表T中的元组分布到n个节点上，可以使用统一的哈希算法对元组中的某个或某几个属性进行哈希，如hash(T.attribute1) mod n，然后根据哈希值将元组放置到不同的节点上。
　　在分区存储的表中处理SQL查询需要使用基于分区的执行策略，如获取表T中某一数值范围内的元组，系统首先为整个表T生成总的执行计划P，然后将P拆分成n个子计划{P1，…，Pn}，子计划Pi在节点ni上独立执行，最后每个节点将生成的中间结果发送到某一选定的节点上，该节点对中间结果进行聚集产生最终的结果。
　　并行数据库系统的目标是高性能和高可用性，通过多个节点并行执行数据库任务，提高整个数据库系统的性能和可用性。最近一些年不断涌现一些提高系统性能的新技术，如索引、压缩、实体化视图、结果缓存、I/O共享等，这些技术都比较成熟且经得起时间的考验。与一些早期的系统如Teradata必须部署在专有硬件上不同，最近开发的系统如Aster、Vertica等可以部署在普通的商业机器上，这些数据库系统可以称得上准云系统。
　　并行数据库系统的主要缺点就是没有较好的弹性，而这种特性对中小型企业和初创企业是有利的。人们在对并行数据库进行设计和优化的时候认为集群中节点的数量是固定的，若需要对集群进行扩展和收缩，则必须为数据转移过程制订周全的计划。这种数据转移的代价是昂贵的，并且会导致系统在某段时间内不可访问，而这种较差的灵活性直接影响到并行数据库的弹性以及现用现付商业模式的实用性。
　　并行数据库的另一个问题就是系统的容错性较差，过去人们认为节点故障是个特例，并不经常出现，因此系统只提供事务级别的容错功能，如果在查询过程中节点发生故障，那么整个查询都要从头开始重新执行。这种重启任务的策略使得并行数据库难以在拥有数以千个节点的集群上处理较长的查询，因为在这类集群中节点的故障经常发生。基于这种分析，并行数据库只适合于资源需求相对固定的应用程序。不管怎样，并行数据库的许多设计原则为其他海量数据系统的设计和优化提供了比较好的借鉴。
　　1.3.2 NoSQL数据管理系统
　　NoSQL[5]一词最早出现于1998年，它是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系型数据库（他认为，由于NoSQL悖离传统关系数据库模型，因此，它应该有一个全新的名字，比如“NoREL”或与之类似的名字[6]）。
　　2009年，Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论[7]，来自Rackspace的Eric Evans再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。
　　2009年在亚特兰大举行的“no：sql(east)”讨论会是一个里程碑，其口号是“select fun， profit from real_world where relational=false；”。因此，对NoSQL最普遍的解释是“非关系型的”，强调键值存储和文档数据库的优点，而不是单纯地反对关系型数据库。
　　传统关系型数据库在处理数据密集型应用方面显得力不从心，主要表现在灵活性差、扩展性差、性能差等方面。最近出现的一些存储系统摒弃了传统关系型数据库管理系统的设计思想，转而采用不同的解决方案来满足扩展性方面的需求。这些没有固定数据模式并且可以水平扩展的系统现在统称为NoSQL（有些人认为称为NoREL更为合理），这里的NoSQL指的是“Not Only SQL”，即对关系型SQL数据系统的补充。NoSQL系统普遍采用的一些技术有：
　　-简单数据模型。不同于分布式数据库，大多数NoSQL系统采用更加简单的数据模型，这种数据模型中，每个记录拥有唯一的键，而且系统只需支持单记录级别的原子性，不支持外键和跨记录的关系。这种一次操作获取单个记录的约束极大地增强了系统的可扩展性，而且数据操作就可以在单台机器中执行，没有分布式事务的开销。
　　-元数据和应用数据的分离。NoSQL数据管理系统需要维护两种数据：元数据和应用数据。元数据是用于系统管理的，如数据分区到集群中节点和副本的映射数据。应用数据就是用户存储在系统中的商业数据。系统之所以将这两类数据分开是因为它们有着不同的一致性要求。若要系统正常运转，元数据必须是一致且实时的，而应用数据的一致性需求则因应用场合而异。因此，为了达到可扩展性，NoSQL系统在管理两类数据上采用不同的策略。还有一些NoSQL系统没有元数据，它们通过其他方式解决数据和节点的映射问题。
　　-弱一致性。NoSQL系统通过复制应用数据来达到一致性。这种设计使得更新数据时副本同步的开销很大，为了减少这种同步开销，弱一致性模型如最终一致性和时间轴一致性得到广泛应用。
　　通过这些技术，NoSQL能够很好地应对海量数据的挑战。相对于关系型数据库，NoSQL数据存储管理系统的主要优势有：
　　-避免不必要的复杂性。关系型数据库提供各种各样的特性和强一致性，但是许多特性只能在某些特定的应用中使用，大部分功能很少被使用。NoSQL系统则提供较少的功能来提高性能。
　　-高吞吐量。一些NoSQL数据系统的吞吐量比传统关系数据管理系统要高很多，如Google使用MapReduce每天可处理20PB存储在Bigtable中的数据。
　　-高水平扩展能力和低端硬件集群。NoSQL数据系统能够很好地进行水平扩展，与关系型数据库集群方法不同，这种扩展不需要很大的代价。而基于低端硬件的设计理念为采用NoSQL数据系统的用户节省了很多硬件上的开销。
　　-避免了昂贵的对象-关系映射。许多NoSQL系统能够存储数据对象，这就避免了数据库中关系模型和程序中对象模型相互转化的代价。
　　NoSQL向人们提供了高效便宜的数据管理方案，许多公司不再使用Oracle甚至MySQL，他们借鉴Amzon的Dynamo和Google的Bigtable的主要思想建立自己的海量数据存储管理系统，一些系统也开始开源，如Facebook将其开发的Cassandra捐给了Apache软件基金会。
　　虽然NoSQL数据库提供了高扩展性和灵活性，但是它也有自己的缺点，主要有：
　　-数据模型和查询语言没有经过数学验证。SQL这种基于关系代数和关系演算的查询结构有着坚实的数学保证，即使一个结构化的查询本身很复杂，但是它能够获取满足条件的所有数据。由于NoSQL系统都没有使用SQL，而使用的一些模型还未有完善的数学基础。这也是NoSQL系统较为混乱的主要原因之一。
　　-不支持ACID特性。这为NoSQL带来优势的同时也是其缺点，毕竟事务在很多场合下还是需要的，ACID特性使系统在中断的情况下也能够保证在线事务能够准确执行。
　　-功能简单。大多数NoSQL系统提供的功能都比较简单，这就增加了应用层的负担。例如如果在应用层实现ACID特性，那么编写代码的程序员一定极其痛苦。
　　-没有统一的查询模型。NoSQL系统一般提供不同查询模型，这一定程度上增加了开发者的负担。
　　……

　　为什么写本书
　　计算机技术已经深刻地影响了我们的工作、学习和生活。大数据及NoSQL技术是当下IT领域最炙手可热的话题，其发展非常迅速，潜力巨大，悄然改变着整个行业的面貌。随着Web 2.0技术的发展，微博、社交网络、电子商务、生物工程等领域的不断发展，各领域数据呈现爆炸式的增长，传统关系型数据库越来越显得力不从心。NoSQL数据库技术的出现为眼下的问题提供了新的解决方案，它摒弃了传统关系型数据库ACID的特性，采用分布式多节点的方式，更加适合大数据的存储和管理。
　　政府和高校都十分重视对大数据及NoSQL技术的研究和投入；在产业界，各大IT公司也在投入大量的资源研究和开发相关的NoSQL产品，与之相应的新兴技术和产品正在不断涌现。这一切都极大地推动了NoSQL技术的发展。
　　大数据处理和NoSQL技术涉及的内容繁多，目前不同公司也有不同的NoSQL数据库产品，而且某一产品往往是为特定的应用而设计的，并不一定能够适用于所有的场景。很多人在学习的初始阶段需要进行大量的摸索和实践，然而目前这方面系统的参考资料却非常少。为了便于所有想了解和掌握NoSQL技术的朋友学习并在学习的过程中少走弯路，笔者将自己在该领域的经验和积累凝聚成了这本书，希望能够推动大数据处理及NoSQL相关技术在国内的发展。
　　本书面向的读者
　　在编写本书时，我们力图使不同背景和职业的读者都能从其中获益。
　　如果你是专业技术人员，本书将带领你快速度进入大数据处理及NoSQL的世界，全面掌握NoSQL及其相关技术，能帮助你使用NoSQL技术解决当前面临的问题或提供必要的参考。
　　如果你是高等院校计算机及相关专业的学生，本书为你在课堂之外了解最新的IT打开一扇窗户，能帮助你拓宽视野，完善知识结构，为迎接未来的挑战做好知识准备。
　　在学习本书之前，应具有如下的基础：
　　· 有一定的Linux操作系统的基础知识。
　　· 有较好的编程基础和阅读代码的能力。
　　· 对数据库知识有一定的了解。
　　如何阅读本书
　　本书一共包括16章，分为三个部分。其中第一部分为理论篇，包括：大数据产生的背景，数据一致性理论、数据存储模型、数据分区与防治策略、海量数据处理方法、数据复制与容错技术、数据压缩技术和数据缓存技术。此部分重点从理论上介绍、分析大数据管理过程中遇到的各方面问题。第二部分为系统篇，包括：键值数据库、列存数据库、文档数据库、图存数据库、基于Hadoop的数据库管理系统、NoSQL数据库以及分布式缓存系统。该部分以理论篇为基础，根据数据存储模型对数据库类型进行划分，每一部分以具体开源数据库为实例进行介绍，涉及系统的架构、安装以及使用等方面，力图使读者对NoSQL数据库有具体的认识。第三部分为应用篇，包括企业应用以及总结和展望。该部分介绍企业如何使用NoSQL数据库解决自身遇到的问题。
　　在阅读本书时，读者可以先系统地学习理论篇的知识，目的是对海量数据处理方法有一个很好的理解，在此基础之上，读者可以对后面的章节进行选择性的学习。本书涉及内容较多，从开源数据库方面讲，包括了Dynamo、Redis、Voldemort、Cassandra、Hypertable、CouchDB、MongoDB、Neo4j、GraphDB、OrientDB、HBase、Hive、Pig、MySQL Cluster、VolteDB、MS-Velocity、Memcached等将近20个数据库。因此，建议读者可以重点学习感兴趣或有一定需求的数据库系统。当然，如果时间允许，还是建议读者系统地学习本书的内容。
　　另外，在系统篇的学习过程中，建议读者能够一边阅读，一边根据书中的指导动手实践，亲自实践本书中所给出的编程范例。
　　致谢
　　在本书的编写过程中，还有很多NoSQL领域的实践者和研究者为本书做了大量的工作，他们是张林林、许翔、程明、王海涌、顾向楠、吴少辉、杨宁、杨华、吴梦迪、任乔意、於洋、张轩等，在此特别感谢。
　　在线资源及勘误
　　本书的勘误、讨论以及相关资料等都会在该网站上发布和更新。
　　在本书的撰写和相关技术的研究中，尽管笔者投入了大量的精力，付出了艰辛的努力，然而受知识水平所限，错误和疏漏之处在所难免，恳请大家批评指正。如果有任何问题和建议，可发送邮件至邮箱。
　　陆嘉恒