1、分布式系统论文题目：NOSQL 数据库专 业 班 级 学 生 学 号 指导教师 2014 年 秋季 学期目录1.引言 .12. NoSQL 数据库类型 12.1 按照 NoSQL 存储模型和特点分类 12.2 根据 CAP 原理分类 .23.NoSQL 架构 .53.1 纯 NoSQL 架构 .53.2 以 NoSQL 作为数据源的架构 .64.典型 NoSQL 数据库概述 .84.1 HBase 简介 .84.2 Redis 简介 94.3 MongoDB 简介 104.4 Cassandra 简介 .114.5 CouchDB 简介 .115.总结 .121NoSQL 数据库1.引言 随着
2、互联网 Web2.0 网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，其相关产品的发展也非常迅速。传统的关系数据库在应付 Web2.0网站时暴露了很多难以克服的问题，主要有包括：不能满足对数据库高并发读写的需求；不能满足对海量数据的高效率存储和访问的需求；不能满足对数据库的高可扩展性和高可用性的需求。另外，许多 Web2.0 网站并不需要关系数据库提供的一些服务，诸如：数据库事务一致性、数据库的写实时性和读实时性、对复杂的 SQL 查询等。因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。NoSQL 是非关系型数据存储的广义定义。它打
3、破了长久以来关系型数据库与 ACID 理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库. 无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。2. NoSQL 数据库类型 2.1 按照 NoSQL 存储模型和特点分类按照 NoSQL 存储模型和特点分类形式如表 1 所示，表 1 参照存储模型的NoSQL 分类中根据 NoSQL 数据库的存储原理，列出了六大类主要的 NoSQL 数据库分类，分别是：列存储、文档型存储、Key-value 存储、图存储、对象存储和 xml 存储。表 1 中仅列出了一些比较常见的 NoSQL 数据
4、库，在所有的这些类型的 NoSQL 数据库中，当前应用较多的就是前三种类型：列存储类型、文档存储、key-value 存储类型。特别需要说明的是，图数据库也可称为面向/基于图的数据库，对应的英文是 Graph database。图数据库的基本含义是以“图”这种数据结构存储和查询数据，不是存储图片的数据库。22.2 根据 CAP 原理分类CAP 理论是设计分布式 web 系统的一个很关键的定律，在设计分布式 Web服务中，通常需要考虑三个应用的属性：一致性、可用性以及分区宽容性。但是在实际的设计中，不可能这三方面同时做的很好。下面详细介绍 CAP 理论中的三个属性：一致性，可以理解为在执行完一次
5、写操作之后，未来的读操作一定可以读到这个新写入的值；可用性，可以理解为系统总是可读可写的；分区容错性，可以理解为系统被即便被分个成无法通信的系统节点仍 然可以正常工作，因此对于分布式系统而言，必须支持分区容错。NoSQL 一定程度上就是基于这个理论提出来的，因为传统的 SQL 数据库（关系型数据库）都是都是具有ACID 属性，对一致性要求很高，因此降低了 A（ availability）和P（partion tolerance） ，因此，为了提高系统性能和可扩展性，必须牺牲C（consistency） ，推翻关系型数据库中 ACID 这一套。 CAP 理论的核心思想是一个数据库不可能同时满足一
6、致性、可用性和分区容错性。依据 CAP 理论，从应用的需求不同，一般对数据库可以从三方面考虑：考虑 CA，这就是传统上的关系型数据库(RMDB) ；考虑 CP，主要是一些 Key-value 数据库，典型代表为 google 的 Big Table；考虑 AP，主要是一些面向文档的适用于分布式系统的3数据库，如 SimpleDB。 不同的应用场景必然会选择不同的 NoSQL 数据库来进行存储操作，例如对于大型网站尤其是 SNS 网站，对于数据的短期存储，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 AP 的方向设计，比如有名的 Tokyo Cabinet 就是 AP 理论的成功产品
7、。 根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类。满足 CA 原则的数据库有 vertica；满足 CP 原则的数据库有MongoDB、HBase、Redis、BigTable、Hypertable、Terrastore、MemcacheDB、BerkeleyDB 等；满足 AP 原则的数据库有Dynamo、CouchDB 、SimpleDB、Cassandra 等。采用 NoSQL 的新型存储架构选用 NoSQL 数据库必须根据特定的应用场景需求来确定。如果关系数据库在开发者的应用场景中很好的工作，并且开发人员又是非常善于使用和维护
8、关系数据库的，那么笔者不建议开发人员采用 NoSQL 数据库；如果开发行业属于金融，电信等以数据为王的关键领域。目前使用的是 Oracle 数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然笔者也建议不要贸然尝试 NoSQL。 然而，在 WEB2.0 的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果开发人员正在经历这些场合，那么笔者建议应该尝试一下NoSQL。 如此多类型的 NoSQL，而每种类型的 NoSQL 又有很多，到底选择什么类型的
9、 NoSQL 来作为存储管理工具并不是一个很好回答的问题，影响选择的因素有很多，而选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。一般情况下，需要根据如下情况考虑：数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化；写入特点。包括 insert 比例、update 比例、是否经常更新数据的某一个小字段、原子更新需求；查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。 NoSQL作为镜像 不改变原有的以 MySQL 作为存储的架构，使用 NoSQL 作为辅助镜像存储，用 No
10、SQL 的优势辅助提升性能。4如图 1， NoSQL 作为镜像，这种架构在原有基于 MySQL 数据库的架构上增加了一层辅助的 NoSQL 存储，代码量不大，技术难度小，却在可扩展性和性能上起到了非常大的作用。只需要程序在写入 MySQL 数据库后，同时写入到 NoSQL 数据库，让 MySQL 和 NoSQL 拥有相同的镜像数据，在某些可以根据主键查询的地方，使用高效的 NoSQL 数据库查询，这样就节省了 MySQL 的查询，用 NoSQL 的高性能来抵挡这些查询。另外一种不通过程序代码，而是通过 MySQL 把数据同步到 NoSQL 中。这种模式是上面一种的变体，是一种对写入透明但是具有
11、更高技术难度一种模式。这种模式适用于现有的比较复杂的老系统，同时也适用于需要把数据同步到多种类型的存储中。MySQL 到NoSQL 同步的实现可以使用 MySQL UDF 函数，MySQL binlog 的解析来实现。对于 NoSQL 和 MySQL 结合，MySQL 中只存储需要查询的小字段，NoSQL 存储所有数据。把需要查询的字段，一般都是数字，时间等类型的小字段存储于 MySQL 中，根据查询建立相应的索引，其他不需要的字段，包括大文本字段都存储在 NoSQL 中。在查询的时候，先从 MySQL 中查询出数据的主键，然后从 NoSQL 中直接取出对应的数据即可。5如图 2， NoSQL
12、 和 MySQL 的结合，这种架构模式把 MySQL 和 NoSQL 的作用进行了融合，各司其职，让 MySQL 专门负责处理擅长的关系存储，NoSQL 作为数据的存储。它有以下优点：第一，节省 MySQL 的 IO 开销，由于 MySQL 只存储需要查询的小字段，不再负责存储大文本字段，这样就可以节省 MySQL 存储的空间开销，从而节省 MySQL 的磁盘 IO。笔者曾经通过这种优化，把 MySQL 一个 40G 的表缩减到几百兆。第二，提高MySQL Query Cache 缓存命中率。由于 Query Cache 缓存失效是表级的，在MySQL 表一旦被更新就会失效，经过这种字段的分离
13、，更新的字段如果不是存储在 MySQL 中，那么对 Query Cache 就没有任何影响。而 NoSQL 的 Cache 往往都是行级别的，只对更新的记录的缓存失效。第三，提升 MySQL 主从同步效率，由于 MySQL 存储空间的减小，同步的数据记录也减小了，而部分数据的更新落在 NoSQL 而不是 MySQL，这样也减少了 MySQL 数据需要同步的次数。第四，提高 MySQL 数据备份和恢复的速度，由于 MySQL 数据库存储的数据的减小，很容易看到数据备份和恢复的速度也将极大的提高。第五，比以前更容易扩展，NoSQL 天生就容易扩展。经过这种优化，MySQL 性能也得到提高。3.No
14、SQL 架构3.1 纯 NoSQL 架构只用 NoSQL 作为数据存储，在一些数据结构、查询关系非常简单的系统6中，可以只使用 NoSQL 解决存储问题，这样不但可以提高性能，还非常易于扩展。在一些数据库结构经常变化，数据结构不定的系统中，也非常适合使用NoSQL 来存储。比如监控系统中的监控信息的存储，由于每种类型的监控信息都不太一样，采用 NoSQL 架构可以避免经常对 MySQL 进行表结构调整，以避免增加字段带来的性能问题。如图 3 纯 NoSQL 架构，这种架构的缺点就是数据直接存储在 NoSQL 中，不能做关系数据库的复杂查询。值得一提的是，有些 NoSQL 数据库已经具有部分关系
15、数据库的关系查询特性，他们的功能介于 key-value 和关系数据库之间，却具有 key-value 数据库的性能并且基本能满足绝大部分 web 2.0 网站的查询需求。比如：MongoDB 就带有关系查询的功能，能解决常用的关系查询。另外，Tokyo Tyrant 数据库带有一个名为 table 的存储类型，可以对存储的数据进行关系查询和检索。一个 table 库类似于 MySQL 中的一个表。 3.2 以 NoSQL 作为数据源的架构以 NoSQL 作为数据源的架构是数据直接写入 NoSQL，再通过 NoSQL 同步协议复制到其他存储，根据应用的逻辑来决定去相应的存储获取数据。7如图 4
16、， 以 NoSQL 作为数据源的架构，纯 NoSQL 的架构虽然结构简单，易于开发，但是在应付需求的变更、稳定性和可靠性上，总是给开发人员一种风险难于控制的感觉。为了降低风险，系统的功能不局限在 NoSQL 的简单功能上，可以使用以 NoSQL 为数据源的架构。在这种架构中，应用程序只负责把数据直接写入到 NoSQL 数据库就 OK，然后通过 NoSQL 的复制协议，把NoSQL 数据的每次写入，更新，删除操作都复制到 MySQL 数据库中。同时，也可以通过复制协议把数据同步复制到全文检索实现强大的检索功能。在海量数据下面，也可以根据不同的规则，把数据同步复制到设计好的分表分库的MySQL 中
17、。 这种架构的优点主要有四点，第一，非常灵活。这种架构可以非常方便的在线上系统运行过程中进行数据的调整，比如调整分库分表的规则、要添加一种新的存储类型等。第二，操作简单。只需要写入 NoSQL 数据库源，应用程序就不用管了。需要增加存储类型或者调整存储规则的时候，只需要增加同步的数据存储，调整同步规则即可，无需更改应用程序的代码。第三，性能高。数据的写入和更新直接操作 NoSQL，实现了写的高性能。而通过同步协议，把数据复制到各种适合查询类型的存储中，能实现查询的高性能，不像以前MySQL 一种数据库就全包了。或者就一个表负责跟这个表相关的所有的查询，现在可以把一个表的数据复制到各种存储，让各
18、种存储用自己的长处来对外服8务。第四，易扩展。开发人员只需要关心写入 NoSQL 数据库，数据的扩展可以方便的在后端由复制协议根据规则来完成。这种架构的缺点在于，需要考虑数据复制的延迟问题，这跟使用 MySQL 的 master salve 模式的延迟问题是一样的，解决方法也一样。 在这种以 NoSQL 为数据源的架构中，最核心的就是 NoSQL 数据库的复制功能的实现。而当前的几乎所有的 NoSQL 都没有提供比较易于使用的复制接口来完成这种架构，对 NoSQL 进行复制协议的二次开发，需要更高的技术水平，所以这种架构看起来很好，但是却不是非常容易实现的。 4.典型 NoSQL 数据库概述
19、4.1 HBase 简介HBase（Hadoop Database） ，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群。HBase 是 Google Bigtable 的开源实现， HBase 利用 Hadoop HDFS 作为其文件存储系统，利用 Hadoop MapReduce 来处理 HBase 中的海量数据，利用 Zookeeper 作为对应。 HBase 最大的特点是面向列，也就是按照 cell 存储的，确定一个 cell 的 key是由 row key，version ，column fami
20、ly， column name 几项组成的。由于 HBase是按照 key 的字母顺序紧凑排列 cells，所以 scan 效率非常高（对应于 b-tree 存储结构） 。HBase 的存储文件格式叫做 hfile。而在一个 Region 中不同列族的数据是存储在不同的 hfile 中的。所以，如果一次数据访问过程中只访问某个column family 的数据，效率会更高。这也使得设计 table scheme 时的column family 定义更加重要。HBase 的另一个特点是，HBase 是复杂，因为HBase 的体系结构几乎完全是继承自 Google 的 BigTable，所以可以说
21、是常见的NoSQL 中最为复杂的，这可以体现在几点上：HBase 的存储是基于 HDFS 的，这表示 HBase 的每次读操作都需要通过 HDFS 层来取得数据，这也在一定程度上决定了 HBase 的随机读性能是比较低的。不像 Cassandra 等平等的 NoSQL 数据库，HBase 集群中的节点是分为 Master 和 RegionServer 的，其中 Master 负责Region 的分配，而 RegionServer 负责存储 Regions 数据，这在一定程度上也为9HBase 引入了单点问题。整个框架是通过一套叫做 ZooKeeper 的程序来协调控制 cluster 内的各个
22、节点的。以上三点涉及到的HDFS，Master，RegionServer ，Zookeeper，这四者都有各自的配置文件，且可配置项繁多，这也使得 HBase 的安装部署比较繁琐。 4.2 Redis 简介REmote DIctionary Server(Redis) 是一个由 Salvatore Sanfilippo 写的 key-value 的高速缓存系统，类似于 Memcached，但是支持更复杂的数据结构List、Set、Sorted Set，并且有持久化的功能。 笔者将从下面三个方面全面地介绍 Redis：第一，key value store，Redis 是一个以 key-value
23、 形式存储的数据库，定位直指 MySQL，用来作为唯一的存储系统；第二，memory cache ，Redis 是一个把数据存储在内存中的高速缓存，用来在应用和数据库间提供缓冲，替代memcachd；第三，data structrue server ，Redis 支持对复杂数据结构的高速操作，提供某些特殊业务场景的计算和展现需求，比如排行榜应用、Top 10 之类等。Redis 最大的特点就是基于内存存储。如果把随机 IO 操作都放到内存中去，把顺序 IO 都放入硬盘中，这样可以大大提高数据操作的速度。Redis 作为一个内存 NoSQL 数据库，就是把内存当做硬盘使用的一个典型范例。Redi
24、s 使用内存提供主存储支持，硬盘做持久性的存储。采用这种架构最大的优点是数据处理速度快，支持高频率的读写；缺点是对设备硬件要求高，处理数据量有限。Redis 是 NoSQL 数据库中的 Key-Value 类型数据库，其可以说是真正的纯粹的NoSQL 类型数据库，因为其与传统的关系型数据库完全撇清了关系，也就是说其与传统的关系型数据库完全是对立的。Redis 由于支持非常丰富的内存数据结构类型，如何把这些复杂的内存组织方式持久化到磁盘上是一个难题，所以Redis 的持久化方式与传统数据库的方式有比较多的差别， Redis 一共支持四种持久化方式，分别是：定时快照方式(snapshot) ，基于
25、语句追加文件的方式(aof)，虚拟内存(vm) ，Diskstore 方式。在设计思路上，前两种是基于全部数据都在内存中，即小数据量下提供磁盘落地功能，而后两种方式则是作者在尝试存储数据超过物理内存时，即大数据量的数据存储，截止到本文，后两种持久化方式仍然是在实验阶段，并且 vm 方式基本已经被作者放弃，所以实际能在生产环10境用的只有前两种，换句话说 Redis 目前还只能作为小数据量存储（全部数据能够加载在内存中） ，海量数据存储方面并不是 Redis 所擅长的领域。4.3 MongoDB 简介MongoDB 是一个可扩展的、高性能、开源、模式自由、面向文档的数据库，使用 C+语言编写，旨
26、在为 web 应用提供可护展的高性能数据存储解决方案。MongoDB 在键值存储和传统关系数据库系统之间建立了一个桥梁。 MongoDB主要特性有：面向文档存储、支持完全索引、高可靠性、自动分片支持云级扩展性、查询记录分析、快速就地更新、支持 Map/Reduce、提供分布式文件系统GridFS、商业支持。除此之外，MongoDB 还具有模式自由、支持动态查询、支持数据复制与的故障恢复、使用高效的二进制数据存储、包括大型对象、支持非常多的语言、文件存储格式为 BSON。 MongoDB 的主要目标是在键/值存储方式以及传统的 RDBMS 系统架起一座桥梁，集两者的优势于一身。Mongo 适合用
27、于网站数据： Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性；MongoDB 适合用于缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层，在系统重启之后，由 Mongo 搭建的持久化缓存层可以避免下层的数据源过载；MongoDB 适合用于大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储；MongoDB 适合用于高伸缩性的场景：Mongo 非常适合由数十或数百台服务器组成的数据库。MongoDB 的路线图中已经包含对MapReduce 引擎的内置支持；用于对象及 J
28、SON 数据的存储：MongoDB 的BSON 数据格式非常适合文档化格式的存储及查询。 MongoDB 的使用也会有一些限制。MongoDB 不适合高度事务性的系统，例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。MonogoDB 不适用于传统的商业智能应用，针对特定问题的 BI 数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。如表 1，是这三种数据库的对比。114.4 Cassandra 简介Cassandra 最初由 Facebook 开发，后来成了 Apache 开源项目，它是一个网络社交云计算方面理想的数据库。它集成
29、了其他的流行工具如 Solr，现在已经成为一个完全成熟的大型数据存储工具。Cassandra 是一个混合型的非关系的数据库，类似于 Google 的 BigTable。其主要功能比 Dynomite（分布式的 Key-Value 存储系统）更丰富，但支持度却不如文档存储 MongoDB。Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作，会被复制到其他节点上去，而对Cassandra 的读操作，也会被路由到某个节点上面去读取。在最近的一次测试中，Netflix 建立了一个 288 个节点的集群。4.5 Co
30、uchDB 简介CouchDB 是用 Erlang 开发的面向文档的数据库系统，不过它不是一个传统的关系数据库，而是面向文档的数据库，其数据存储方式有点类似 lucene 的12index 文件格式，CouchDB 最大的意义在于它是一个面向 web 应用的新一代存储系统。作为一个分布式的数据库，CouchDB 可以把存储系统分布到 n 台物理的节点上面，并且很好的协调和同步节点之间的数据读写一致性。CouchDB 支持 REST API，可以让用户使用 JavaScript 来操作 CouchDB 数据库，也可以用JavaScript 编写查询语句，可以想像一下，用 AJAX 技术结合 Co
31、uchDB 开发出来的 CMS 系统会是多么的简单和方便。 CouchDB 还有一个更加商业化的“表亲”Couchbase，不过它提供缓存功能，更好的分片，增量查询，更好的索引和一些其他的功能。其实 Couchbase 与 CouchDB 也是紧密相关的，Couchbase 产品包含了 CouchDB 的一个副本。5.总结 本文给出了 NoSQL 数据库的综述，包括 NoSQL 数据库类型、当前采用NoSQL 数据库进行存储的新型存储架构以及一些典型 NoSQL 数据库的特性介绍。NoSQL 是一个新兴的数据库，数据库架构师在选择 NoSQL 作为存储管理工具是应该根据特定应用的具体需求场景以及数据类型和操作方式选用适合自己的存储架构和 NoSQL 数据库。
