《计算机科学与技术硕士学位论文分布式KeyValue数据库及其一致性研究.doc》由会员分享，可在线阅读，更多相关《计算机科学与技术硕士学位论文分布式KeyValue数据库及其一致性研究.doc（65页珍藏版）》请在三一办公上搜索。
1、分类号 密 级 U D C 编 号1 0 4 8 6武汉大学硕士学位论文分布式Key-Value数据库及其一致性研究研 究 生 姓 名：学 号：2010206350016指导教师姓名、职称：胡继承 教授专 业 名 称：计算机科学与技术研 究 方 向：计算机软件与理论二一二年五月Dissertation Submitted to Wuhan UniversityStudy of Distributed Key-Value Database and Consistency IssueBy Shiquan YeUnder the Guidance ofProfessor Jicheng HuMay,
2、 2012郑 重 声 明本人的学位论文是在导师指导下独立撰写并完成的，学位论文没有剽窃、抄袭、造假等违反学术道德、学术规范和侵权行为，否则，本人愿意承担由此而产生的法律责任和法律后果，特此郑重声明。 学位论文作者（签名）：年 月 日摘 要互联网已进入全面参与的 Web 2.0 时代，伴随而来的是用户量和数据量的爆炸式增长。传统关系型数据库在应付 Web 2.0 网站，特别是超大规模和高并发的社交型网站已经显得力不从心，暴露出很多难以克服的问题。NoSQL 数据库放弃了关系型数据库中的关系模型，通过去除数据之间的耦合使数据库更为适应现代高性能服务架构，从而达到存储系统的高性能。另外，传统的集中式
3、存储无法满足海量数据的需要，为保证高可用性、高可靠性和经济性，越来越多互联网企业采用分布式存储的方式来存储数据，采用冗余存储的方式保证数据的可靠性。本文在研究 Key-Value 存储储系统的基础上，着重研究分布式系统下的数据一致性机制，一致性机制是保证分布式存储系统能够正常提供服务的基础，在某些特定的业务场景中有着苛刻的要求。著名的分布式 Paxos 算法解决的是分布式系统一致性问题，本文在该算法的基础上，提出并实现了多轮 Paxos 算法，以及领导选举算法，从而保证分布式存储系统的一致性。本系统在单机存储上使用 Berkeley DB 作为底层存储引擎，在此基础上，通过实现节点管理、节点通
4、信、冗余备份和一致性算法，解决了分布式系统中数据一致性性等难点问题，最终实现了一套分布式 Key-Value 存储系统。相比于普通的 Key-Value 数据库，本文提出的数据库具有分布式特点，各个节点共同组成一个分布式分布式网络存储服务，能够保证数据的强一致性，具有极高的错误容忍能力，而且系统自带节点管理功能，方便扩展性能，进行高密度地部署。关键词：NoSQL；Key-Value存储；分布式系统；一致性；Paxos算法ABSTRACTThe Internet has come into the web2.0 era which brings the explosive growth of u
5、ser and data. It has been hard for traditional relational-database to deal with Web2.0 website especially large scale SNS website. NoSQL database is more comfortable for the modern architecture of high-performance service, because it removes the data-structured coupling, which improves the efficienc
6、y of data store. On the other hand, traditional centralized data store cant satisfy the requirements of big data. In order to gain high availability, high reliability and economical benefit，more and more internet enterprises take distributed database as their data store, which ensures its reliabilit
7、y by replication.This article studies distributed database and the consistency of distributed system. The key problem of distributed system is maintaining the consistency of data, which is very strict in some cases. A lot of algorithm is introduced to solve this problem and the Paxos algorithm is co
8、nsidered to the most effective approach in dealing with consistency. This article use multi-paxos algorithm which is based on Paxos to solve the consensus of distributed data store.This article builds a distributed key-value database. We use Berkeley DB as its local store engine. By implementing nod
9、e communication, replication and consistency mechanism, we solve the main problem of distributed system, such as consistency, availability, redundancy and fault tolerant. Compared to ordinary key-value database, this key-value data store is a distributed system, all node make up a distributed networ
10、k store service, ensuring the strong consensus of data and provides high-availability, high-reliability, scalability and fault-tolerant for data store. Key words: NoSQL; Key-Value Store; Distributed System; Consensus; Paxos Algorithm目 录摘 要IABSTRACTII第1章 绪论11.1 课题的研究目的和意义11.2 相关领域的研究现状21.3 论文组织结构3第2章
11、 NoSQL存储系统的研究32.1 关系型数据库的缺陷32.2 NoSQL简介52.3 Key-Value存储系统的优势和不足72.3.1 Key-Value数据库的优势72.3.2 Key-Value数据库的不足72.4 如何使用Key-Value数据库82.4.1 Key-Value数据库的设计方法82.4.2 Key-Value数据库与关系型数据库的配合使用102.4.3 Key-Value缓存的使用112.5 国内外 NoSQL 数据库的研究和分析122.5.1 满足极高读写性能需求的Key-Value数据库122.5.2 满足海量存储需求和访问的面向文档的数据库132.5.3 满足高
12、可扩展性和可用性的面向分布式计算的数据库132.5.4 面向图存储的数据库14本章小结14第3章 分布式系统的复制技术153.1 复制的目的153.2 复制的上下文163.3 复制的模型173.4 分布式系统的复制193.4.1 主动复制203.4.2 被动复制213.4.3 半主动复制223.4.4 半被动复制223.5 数据库的复制233.6 复制的策略233.6.1 Eager Primary复制243.6.2 Eager Update Everywherre复制253.6.3 基于原子性组播的复制263.6.4 懒惰式复制27本章小结27第4章 分布式系统的一致性研究284.1 一致性
13、模型284.1.1 强一致性模型294.1.2 顺序一致性模型294.1.3 因果一致性模型304.1.4 FIFO一致性模型314.1.5 最终一致性324.2 一致性协议334.2.1 基于主备份的协议334.2.2 复制的写协议36本章小结36第5章 分布式一致性算法的研究和实现385.1 系统架构385.2 基于Paxos的一致性算法395.2.1 Paxos算法解决的问题395.2.2 Paxos算法的理论405.2.3 Paxos算法的内容425.2.4 Paxos算法的实现445.3 系统的性能分析49本章小结51第6章 总结与展望526.1 总结526.2 展望52参考文献52
14、致谢56第1章 绪论1.1 课题的研究目的和意义互联网早已进入 Web 2.0 时代，这期间出现很多大规模现代网站，带来信息量爆炸式地增长。面对海量的用户以及海量的数据，传统的关系型数据库在网站的支撑上显得越来越吃力，数据库性能瓶颈越来越突出。虽然出现很多相对应的解决方案，比如水平切分数据库、引入内存缓存等方法，但仍然很难从根本上解决关系型数据库的缺陷。这主要归结于关系型数据库复杂的关联和耦合，这些天然缺陷导致关系型数据库很难再架构上和部署上进行切分和扩容，从而影响了数据库的整体性能，并且，数据库的扩展和维护变得相当复杂。在这样的技术背景下，很多互联网企业内部的团队开发出了 NoSQL 数据库
15、，并开放源码，在业界得到广泛地应用。NoSQL 数据库抛弃了传统关系型数据库的关系模型，取消了复杂的关系模式和字段类型，通过在业务架构上简化存储模型使之适应现代高性能网站的架构，实现存储系统的高可扩展性和高性能并发读写的能力。本文提出的 Key-Value存储系统就属于 NoSQL 的一种类型。早在 1991 年，伯克利加州大学就开发出第一款 Key-Value 数据库：Berkeley DB7 ， Key-Value 数据库的出现是为了应付数据的高并发读和写，但是对于大多数互联网企业来说，现有的 Key-Value 数据库部署和维护的成本偏高，这无疑阻碍了 Key-Value 数据库在业界的
16、广泛使用。特别在云计算领域，如果不能方便地部署和维护云端的数据服务器，将影响云端提供服务的质量和稳定性。因此，一种具有高可扩展性的新型 Key-Value 存储系统能够给业界开发人员带来方便。当前研究背景下，多数对 Key-Value 数据库的研究都将精力集中在单机数据存储层面，比如固态存储，flash存储以及增量型存储引擎等技术的使用已将单机的数据存储性能发挥到极致。但是多数开源的 Key-Value 数据库并没有提供分布式的功能，更没有结合硬件配置的特点对存储系统有综合的考虑。因此，在降低分布式部署的成本和难度上比较乏力，业界需要一种对此有较好支持的新型分布式 Key-Value 存储系统
17、。本课题的目的是设计并实现一种分布式 Key-Value 数据存储系统，它能够保证数据的高可靠性和一致性，具有优秀的错误容忍能力，而且方便对存储系统扩容，为开发人员带来极大的方便，适合用于互联网企业的大规模数据存储，为云计算的存储平台提供优秀的解决方案。1.2 相关领域的研究现状如今 NoSQL 在业界得到了广泛地应用，各大互联网公司相继开发出自己的 NoSQL 存储系统，并贡献给开源界。NoSQL 在理论上最早来自 Google 提出的 BigTable1 ，BigTable 是 Google 设计用来分布式存储大规模结构化数据的，Google 在很多项目上用 BigTable 来存储数据，
18、包括网页查询、Google Earth和Google 金融。Amazon紧随其后提出了Dynamo存储系统2 ，Dynamo是面向Amazon自有的电子商务应用的，使用广域分布的大规模集群提供高可靠的对象存储服务，主要存储1M左右甚至更小的内容，如购物车、推荐列表等。BigTable和Dynamo为各自的企业提供了高性能的存储服务，成为整个网站架构的存储基石。遗憾的是，两者都没有开放源码。以 Facebook 和 Twitter 为代表的社交型互联网企业相继开发出自己的 Key-Value 存储系统，并且贡献给开源界。Facebook 开发的 Cassandra8 是一套高度可扩展、最终一致、
19、分布式的结构化 Key-Value 存储系统，Cassandra 结合了 Dynamo的分布式技术和Google 的BigTable 数据模型。Cassandra 具有Dynamo 的最终一致性；同时 Cassandra 相比典型的 Key-Value 数据存储模型更为丰富，它提供与 Google 的 BigTable 相似的、基于 ColumnFamily的数据模型。国内的互联网公司对于 NoSQL 的应用也越来越多，而且相继出现了自主研发的 Key-Value 存储系统，包括淘宝网的 Tair，豆瓣网的 BeansDB和人人网的 Nuclear。这些开源存储系统紧密结合自身的业务特点，为企
20、业提供强有力的数据支撑。但是由于这些系统缺少通用性，仅限自家使用，没有在业界得到广泛地使用。目前开源界出现的 Key-Value 数据库有 Memcached、Redis、MemcacheDB等，这些数据库主要关注于单机的存储和实现，却反分布式的考虑，难以在超大型的分布式系统中使用，同时它们在数据的一致性上不够苛刻，难以满足一些业务场景的要求。纵观开源界和工业界，Key-Value 产品呈现百花齐放的态势，各种特性的产品都有出现，然而根据 CAP 理论4 ，不可能存在一种完美的和通用的 Key-Value 产品，对于互联网企业，特别是拥有海量数据和大规模访问的网站来说，有必要结合自身业务特点开
21、发出适合自己的 Key-Value 存储系统。1.3 论文组织结构第1章 该部分对此研究展开的背景做了阐述，随后研究和国内外 Key-Value 存储系统的发展状况。第2章 该章节研究了 Key-Value 存储系统，包括其产生的意义、特性和应用场景，并分析了目前各个开源产品的不足之处。第3章 该部分研究了传统数据库的复制技术分布式系统中的复制技术，指出了复制技术的目的，并把复制技术抽象出了一个通用的五阶段模型，在此基础上论证了各种技术方案的优点和不足。第4章 该部分研究了现有分布式系统的一致性模型，以及用来解决一致性问题的一致性协议，指出强一致性是不可能实现的，必须根据应用特点适当放松一致性
22、要求。进而对比了集中要求较弱的一致性模型和一致性协议。第5章 该部分详细描述了Paxos一致性算法的设计和实现，在此基础上，提出了多重Paxos算法解决容错问题，以及使用领导选举算法解决分布式环境中Master故障的问题。第6章 该部分对此 Key-Value 存储系统做了功能测试和性能分析，并给出了详细的测试数据和图表分析。第2章 NoSQL存储系统的研究2.1 关系型数据库的缺陷 互联网早期发展的时候，由于用户基数小，网站的访问量不大，因而服务器的负载相对小很多，当时对网站的架构没有很多讲究，大多数互联网应用着眼于内容，吸引更多的用户量，对于服务器来说，只要能工作就好，在性能上考量不多。而
23、且那个时候的网站主要以HTML静态网页的方式呈现，复杂一点的应用会加上留言板或者简单的BBS版块等。此类应用负载很轻，数据量也小，因此很多网站的后端存储采用简单的纯文本格式，加上自定义的分割符来结构化数据，这种数据存储方式这迟早会暴露出很多缺陷的，比如在性能上当数据量大的时候查询效率显著降低，在功能上扩展性非常难。 随着互联网的发展，简单的静态网页无法满足日益复杂的网站功能，以CGI的出现标志着动态网站的时代到来，简单的数据存储方案显然无法满足动态网站的复杂需求。为此，人们开始寻找更为合适的数据存储方式，先后开发出Berkeley DB和gdbm两类数据库，在早期以C和Perl做为编程语言的C
24、GI应用中得到广泛地应用，但是这两个数据库是嵌入式的，它们以程序库而非数据库服务的方式提供给开发者使用，难以适应愈发复杂的动态网站的需求，另外两种数据库只能支持简单的存储结构，无法提供复杂一点的关系型数据查询功能，这大大限制了它们的应用。 专注于企业级软件开发的Oracle和IBM敏锐地感觉到市场需求，两者分别开发出大型关系型数据库Oracle和DB2，在各种中小型网站中得到广泛地使用，大大推动了网络应用的发展。关系型数据库的出现是计算机数据管理发展史上一个重要的里程碑，由于关系型数据库具有数据结构化、最低冗余度、较高的程序与数据独立性、易于扩展、易于编制应用程序等优点，因此关系型数据库作为网
25、络应用的基础设施占据了数据持久化的几乎所有方案。 自上世纪90年代以来，以Linux为代表的开源应用成为全球信息化建设的重要力量，其中Apache长期占据Linux网站服务平台和服务器软件的主角，与此同时，开源的关系型数据库MySQL一经推出就迅速占领市场份额，这个以免费、开源、功能全面且性能稳定著称的数据软件和Linux、Apache、PHP一起被称为LAMP成为了WEB 1.0时代无可争议的网络开发套件。在很长一段时期内，以MySQL、Oracle、SQLServer、DB2为代表的关系型数据库近乎完美地支撑着互联网的数据存储，无论是在企业级软件还是互联网应用中，它们的稳定性都经受住了实践
26、的检验。 在信息化发展历程中，WEB 2.0悄然而至，互联网由原来的自上而下的由少数资源控制者集中控制主导的互联网体系转变为自下而上的由广大用户集体智慧和力量主导的互联网体系。在海量用户的参与下，网站规模日益庞大，数据量呈爆炸式增长，网站承受的访问压力与日俱增，MySQL数据库服务器面对大规模数据的查询显得不堪重负，严重影响网站的访问速度和用户体验。在找到解决方案之前，让我们来分析MySQL性能瓶颈的问题来自哪些地方： 从单机数据库角度分析，MySQL数据库的存储引擎非常复杂，这是因为关系型数据库必须支持schema特性和复杂的SQL查询语句，所有的关系型数据库都无法回避这个问题，因此关系型数
27、据库的存储引擎在设计和实现上都很精密和复杂，由此带来IO的大大增加，导致底层访问效率的降低而且性能优化无从下手。每一次数据库的查询和插入都需要扫描大量的记录，在承受大规模访问量的时候，磁盘作为计算机系统最慢的存储部件，频繁的IO操作严重拖垮访问速度，以往不明显的IO性能急剧下降。更为严重的情况是，当需要对数据库表的字段进行增加或者删除时，数据库所耗费的IO更是巨大无比，负载较重的数据库在这个过程中往往几乎被拖垮而无法正常提供服务。 从多机角度来看，MySQL的可扩展能力并不强。面对海量数据，单机数据库服务器不可避免地出现性能瓶颈，此时对数据库的横向扩展是唯一的解决方案，但是一般数据库结构设计上
28、往往存在复杂的关系模型和依赖关系，寻找一种良好的切分数据库方案并不是一件容易的事情，有时甚至是不可能的，而对数据库进行镜像又会带来数据一致性的问题。 这期间人们也摸索出了很多新的方式来解决MySQL的性能瓶颈，在互联网应用中，比较热门的集中解决方案是： （1）使用Memcached。Memcached是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动的网站的速度。一般把Memcached作为MySQL数据库的前端缓存层，可以大量减轻MySQL的压力，但是这种方案也有弊端，比如Memcached把所
29、有数据都保存在内存，不支持数据持久化的功能，这意味着，一旦Memcached服务器崩溃，突然爆发的数据库压力降拖垮MySQL服务器，导致网站无法访问。 (2) MySQL主从分离和读写分离。核心思想是把MySQL数据库的读和写分开，一台服务器作为主机，一台或多台服务器作为从机。主机会把数据库的变化记录到日志，一旦这些变化被记录到日志，就会立刻被送到从机，从机根据日志实现数据的更新，进而达到数据一致性的目的。这种方式能够避免单一MySQL在同时处理大量的读写请求时效率较低的问题，但是这个方案操作复杂，优化程度不高。 （3）MySQL分库分表。通过MySQL的库或者表进行切分，交由不同的服务器分别
30、提供服务，但是这个方案可行性不高，因为表中的数据之间往往存在复杂的依赖关系，切分难度较大。以上几种方案或多或少提升了数据库的负载能力，但是优化程度有限而且增加了数据库维护和配置的成本，只有从根本上变革现有数据库的架构才能带来性能的突破性提升。2.2 NoSQL简介 NoSQL一词首先是Carlo Strozzi在1998年提出来的，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。不过，NoSQL的发展慢慢偏离了初衷，Carlo Strozzi也发觉，其实我们要的不是”no S
31、QL”，而应该是”no relational”，也就是我们现在常说的非关系型数据库了。NoSQL不同于以往关系型数据库之处在于使用松散耦合、方便扩展的数据模型来设计应用的数据结构和数据关联，以提升数据库的可扩展性，从而达到更高性能，概括起来，NoSQL得到广泛应用得意与几点原因：（1） 对数据库高并发读写的需求 Web2.0时代的网站特别是SNS类网站能够根据给用户提供定制的个性化网站，而且允许用户参与创建互联网的内容，因此这类互联网应用的数据库压力非常大，不仅要支持很高的查询请求，更重要的是对数据库的写请求也非常高。关系型数据库应付查询请求还可以接受，但是对于高并发的写请求，磁盘的IO就很难
32、承受了。（2）对海量数据的高效率存储和访问的需求 类似Friendfeed，twitter，Facebook这样的SNS网站，每天要存储用户产生的海量信息，twitter被称为地球的脉搏，每天产生2亿条信息，如果使用关系数据库来存储这些数据，在一张上亿条亿条记录的表里面进行SQL查询，效率非常低，对于这类网站来说是不可以接受的，必须寻找一种高效存储和访问海量数据库的方法，才能构建一个支持海量用户的互联网应用。（3） 对数据库的高可扩展性和高可用性的需求 在网站架构的各个部分中，整个网站的架构都是围绕着数据库进行，数据库存储最有价值的信息，是网站的基石所在，正因为如此，对数据库的扩展非常困难，它
33、不像web应用服务器，可以简单的通过增加服务器的数量来分担负载压力，对数据库的扩展将影响到上层应用，如何实现24小时不间断的提供服务，让数据库平滑升级和扩展一直是工程师最头疼的问题。随着网站规模和用户量的增大，往往必须面对这个问题。 正是因为关系型数据库有了以上种种的缺点，因此才有了使用NoSQL的必要。NoSQL使用Key-Value进行存储，同时，大多数的NoSQL数据库使用内存来保存数据，然后经过一段时间后将数据同步到磁盘中，由于使用内存进行读写， 很好地满足了应对高并发读写的要求。其次，NoSQL数据库提供了根据key值进行横向分表，已经主从数据库互备，来实现在线系统的数据的动态迁移，
34、服务器在线扩展和数据的高可用性。需要指出的是，NoSQL并不是要取代关系型数据库，事实上，NoSQL数据库的功能是关系型数据库的一个子集，也就是说NoSQL数据库可完成的工作都可以由关系型数据库完成，一般NoSQL数据库更关注数据的存储，能够提供更高的性能和可扩展性。2.3 Key-Value存储系统的优势和不足2.3.1 Key-Value数据库的优势Key-Value数据库作为NoSQL数据库最主要的类型，占据着各类NoSQL产品的半壁江山，因为其高度的可扩展能力、超高性能的读写能力以及灵活的模式，Key-Value数据库成为了关系型数据库的有力补充，在互联网企业得到了广泛地使用。（1）
35、高度可扩展 可扩展性是NoSQL数据库区别于传统关系型数据库最为本质的一个特点，而Key-Value数据库去除掉了关系模型中数据的复杂关系，使得数据可以很容易地分布到服务器存储集群上进行存储，而且服务器之间无需相互通信，这就大大提升了存储架构的灵活性和可扩展性。（2） 海量存储和超高性能读写能力 因为有高度可扩展性的特点，Key-Value数据库可以把很多廉价的PC作为存储器，通过增加存储器的数量达到海量存储和超高性能的吞吐能力。以Google、Facebook和Amazon为代表的互联网巨头都是利用这个特点来创建自己的数据中心。（3） 灵活的数据模型Key-Value数据库抛弃了传统关系型数
36、据库的scheme机制，只保留简单的键值对应关系，在数据结构上不做严格的要求，因此在数据库中添加、删除和修改字段非常容易，不会对服务器性能产生太大的影响，而这对于传统关系型数据库来说，特别是业务已经定型的情况下，将带来性能的急剧下降。2.3.2 Key-Value数据库的不足尽管Key-Value数据库有很多传统关系型数据库没有的优点，但它毕竟只是关系型数据库的一个补充，它有自身的不足之处，并不能替代关系型数据库。最明显的不足当然是不支持关系型数据库的scheme特性，为了高度可扩展能力和高性能的读写能力，Key-Value牺牲了数据之间的关系，但这就要求开发人员在设计上有良好的建模和规划，对
37、于一些逻辑关系较为复杂的业务，Key-Value数据库可能并不合适。所以在大多数应用场景下，Key-Value数据库都是作为传统关系型数据库的有力补充，两者配合使用才能发挥各自的最佳功能和性能。另外一个不足之处在于Key-Value数据库提供的功能没有关系型数据库丰富，关系型数据库对开发者提供了一套可编程的操作接口-SQL语句，大多数业务业务逻辑和数据模型的表达通过表的设计以及运行时的SQL语句就能进行解释，而Key-Value数据库一般只是针对某些特性设计的，在通用性上有所欠缺，需要架构师在众多Key-Value数据库中挑选适合业务场景的产品，这就增加了项目的成本和复杂度。还有一个不足之处是
38、Key-Value数据库对事务的支持不够，根据CAP理论，consistency(数据一致性)，Availability(可用性)，Partitions(网络可分性)这三者 只能同时满足其中的两个。对于传统关系型数据库，它满足了Consistency和Availability，但正是因为如此，所以它在 Partition上就很难做得好。而对于很多的Key-Value数据库而言，它更强调的是Availability和Network Partition，所以在Consistency上做了弱化，大多数Key-Value数据库不支持事务，为了达到高可用性牺牲了一致性，所以在某些对事务要求非常苛刻的场景
39、，比如金融交易系统中，Key-Value数据库是不合适的。本文解决的一个核心问题是分布式Key-Value数据库的一致性问题，通过引入Paxos算法6 来达到数据的强一致性，在一致性上丰富了现有Key-Value数据库的产品。2.4 如何使用Key-Value数据库2.4.1 Key-Value数据库的设计方法与传统关系型数据库不同，Key-Value数据库是没有模式的，因此在使用方法和结构设计上与关系型数据库也有区别。Key-Value数据库在设计上的核心思想是把业务数据切分成一个个键值表，各个表没有依赖关系。下面以一个实例来说明其设计特点。考虑设计一个小型数据库来存储“学生、地址、科目、成
40、绩”这些信息，关系型数据库的经典设计方式如图2.1所示。而Key-Value数据库的设计方式如图2.2所示。 图2.1 关系型数据库设计图2.2 Key-Value数据库的设计对比图2.1和图2.2，关系型的数据库设计采用4个表分别存储学生、课程、地址和成绩，每张表都用一个id来唯一标识一条记录，这个id是数据库内部使用的，对用户不透明。其中Address表和Students表存在依赖关系，Students和Courses通过Scores联系在一起，这种设计方式能有效避免数据冗余，从而满足关系型数据的设计范式。而在Key-Value数据库的设计里只需要两个集合就能抽象出业务数据，原因在于Key
41、-Value数据库是模式自由的。以Scores来说，在关系型数据库设计中将其单独作为一个表是因为Students和Scores是一对多的关系，如果将Scores与Students表联合在一起，那么就会出现数据冗余，并且以后新增一门课程时扩展困难。而对于Key-Value数据库就不同了，其Scores字段就是一个BSON格式的数据，BSON格式固有的模式自由特性使得它可以将Scores包含在内而无需另建一个Scores集合，而且以后扩展非常方便，比如以后需要给Scores新增一个阅卷时间的字段，直接在BSON数据中插入这个值即可。当然，为了减少数据冗余，可以将Courses建立为一个集合，同关系
42、型数据库设计类似。对比关系型数据库，Key-Value数据库的设计有几个优点：首先，数据检索时不用进行表间的连接操作，这能减少一笔不小的开销；其次，合入一起的数据在磁盘上的存放更加密集，能更好地利用IO缓存从而加快数据的的读取和写入；另外，这种设计方式无需担心扩展性问题，无论是添加、删除还是更改数据库字段都非常容易。2.4.2 Key-Value数据库与关系型数据库的配合使用如前所说，Key-Value数据库一般用作关系型数据库的有力补充，两者需要配合使用才能扬长避短，使各自的性能发挥到极致，我们将使用一个典型的使用场景来具体说明这个问题。考虑互联网中一个非常热门的网络应用-博客系统，其存储的
43、核心数据是日志，在关系型数据库中，每篇日志对应一条记录，其字段分别为id、author_id、title、publish_date、tag、body_text等，这种设计方式存在一些问题：（1） 对于博客系统来说，相比于其它字段，日志的文本数据所占存储空间非常大，有可能占到整个数据库90%的存储空间，然而日志文本一般不会作为检索条件，把这样一个字段放在数据库中只是徒增了数据库的大小，对业务逻辑没有多大的作用，反而降低了数据库的整体性能。（2） 对于日志文本，为了解约存储空间，一般采用变长字符串类型存储，而在关系型数据库中，变长字符串的操作效率远远低于定长字符串，因此，用户对日志的添加和更改操作
44、将严重拖垮数据库整体性能，特别是访问量大的时候，引起数据库服务器宕机，导致其它用户无法读取博客日志。（3） 随着日志文本的不断积累，庞大的文本日志使数据库不断膨胀，运维人员将不得不时刻监控数据库的存储状态，一旦容量达到极限就要分割数据库，对数据库进行扩容，根据前面的讨论可知，这不是一项容易的操作。引入Key-Value数据库可以解决这种数据不平衡的问题，考虑把关系型数据库中的body_text字段替换为body_id，然后把日志文本保存在Key-Value数据库中：，如此：（1） 关系型数据库中的文本字段不再存储变长的字符串，仅仅存储整形的id，处理效率将大大提高。（2） 把数据量小但是经常作
45、为检索条件的数据存储在关系型数据库中，而把数据量大的文本数据交给擅长此任务的Key-Value数据库，从而实现数据的无耦合分离，充分发挥各自的存储性能，相比仅仅使用关系型数据库，在架构上是一个非常好的优化。（3） 由于关系型数据库不再存储日志文本，其存储压力大大降低，无需对其频繁监控和扩容，扩容问题转移给了负责存储大规模日志数据的Key-Value数据库，而这恰好是Key-Value数据库最大的优势。所以这种架构减少了系统的复杂度，便于维护和扩展。（4） 由于经常被用作检索条件的字段依然存储在关系型数据库中，所以依然能够对日志进行各种复杂的查询，发挥关系型数据库的优势。2.4.3 Key-Va
46、lue缓存的使用此类应用中最为典型的是Memcached，许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但是随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、网站显示延迟等重大影响。这时Memcached就派上用场了，Memcached是高性能的分布式内存服务器，一般地使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度和可扩展性。 图2.3 Memcached架构图 如图2.3所示，使用Memcached时，读取数据先尝试从Memcached服务器读，没有则从RDBMS读取，然后把读取的数据写入Mem
47、cached缓存起来，这样下次读取同样的数据就不用从RDBMS读了。往Memcached写数据的时候，一般把关系数据库中一条记录的id作为key，其他字段的数据组装成json格式的数据作为value。2.5 国内外 NoSQL 数据库的研究和分析目前国内外NoSQL运动风起云涌，各种类型的NoSQL数据库层出不穷，令人眼花缭乱，很多互联网公司相继把私家使用的NoSQL数据库开源出来，供业界享用。概括起来，目前主要存在三种类型的NoSQL数据库：2.5.1 满足极高读写性能需求的Key-Value数据库代表产品是Redis、Tokyo Cabinet和Flare，以Redis为例： Redis是一个开源的高级Key-Value内存数据库，所有数据都保存在内存中，对数据的操作也在内存中进行，因此，Redis具有极高的读写性能，每秒可以支持超多十万多次的读写操作。另外，Redis还提供了持久化机制，可以定期将数据写入磁盘。除了超高的性能，Redis还提供了丰富的数据类型，最主要的是支持List
