工程硕士论文关于NoSQL数据库技术的研究及应用.docx
《工程硕士论文关于NoSQL数据库技术的研究及应用.docx》由会员分享，可在线阅读，更多相关《工程硕士论文关于NoSQL数据库技术的研究及应用.docx（16页珍藏版）》请在冰豆网上搜索。
工程硕士论文关于NoSQL数据库技术的研究及应用
中图分类号：
论文编号：
专业硕士学位论文
关于NoSQL数据库技术的研究及应用
作者姓名
学科专业
指导教师
培养院系
ResearchandApplicationof
NoSQLDatabaseTechnology
ADissertationSubmittedfortheDegreeofMaster（Master’sDegree）
Candidate：
Supervisor：
中图分类号：
论文编号：
硕士学位论文
关于NoSQL数据库技术的研究及应用
作者姓名申请学位级别
指导教师姓名职称
学科专业研究方向
学习时间自年月日起至年月日止
论文提交日期年月日论文答辩日期年月日
学位授予单位学位授予日期年月日
关于学位论文的独创性声明
本人郑重声明：
所呈交的论文是本人在指导教师指导下独立进行研究工作所取得的成果，论文中有关资料和数据是实事求是的。
尽我所知，除文中已经加以标注和致谢外，本论文不包含其他人已经发表或撰写的研究成果，也不包含本人或他人为获得北京航空航天大学或其它教育机构的学位或学历证书而使用过的材料。
与我一同工作的同志对研究所做的任何贡献均已在论文中作出了明确的说明。
若有不实之处，本人愿意承担相关法律责任。
学位论文作者签名：
日期：
年月日
学位论文使用授权书
本人完全同意北京航空航天大学有权使用本学位论文（包括但不限于其印刷版和电子版），使用方式包括但不限于：
保留学位论文，按规定向国家有关部门（机构）送交学位论文，以学术交流为目的赠送和交换学位论文，允许学位论文被查阅、借阅和复印，将学位论文的全部或部分内容编入有关数据库进行检索，采用影印、缩印或其他复制手段保存学位论文。
保密学位论文在解密后的使用授权同上。
学位论文作者签名：
日期：
年月日
指导教师签名：
日期：
年月日
摘要
NoSQL是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。
NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
关键词：
NoSQL，数据库，趋势，非关系型
Abstract
NoSQLisanewdatabaserevolutionarymovement,earlysomeoneputsforwardto2009,developmenttrendofgrowing.NoSQLadvocatesadvocatestheuseofnon-relationaldatastorage,relativetotherelationaldatabasewithuse,thisconceptisinjectedintoanewthinking.
Keywords:
NoSQL,Database,trend,Non-relational
目录
第一章绪论1
1.1NoSQL数据库的定义1
1.1.1NoSQL数据库简介1
1.1.2NoSQL数据库的发展1
1.2NoSQL数据库的特点3
1.2.1NoSQL数据库的优点3
1.2.2NoSQL数据库的缺点4
1.3本文研究思路和结构安排4
1.3.1本文研究思路和过程4
1.3.2论文的结构安排4
第二章NoSQL数据库技术的应用4
2.1几种常见的NoSQL数据库4
2.2关于MongoDB的实际操作10
结论11
参考文献12
致谢13
第一章绪论
1.1NoSQL数据库的定义
1.1.1NoSQL数据库简介
NoSQL（NoSQL=NotOnlySQL），意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。
NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。
而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
计算机体系结构在数据存储方面要求具备庞大的水平扩展性，而NoSQL致力于改变这一现状。
Google的BigTable和Amazon的Dynamo使用的就是NoSQL型数据库。
1.1.2NoSQL数据库的发展
随着互联网web2.0网站的兴起，非关系型的数据库成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。
而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1．Highperformance-对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。
关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。
其实对于普通的BBS网站，往往也存在对高并发写请求的需求。
2．HugeStorage-对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。
再例如大型web网站的用户登录系统，
3．HighScalability&&HighAvailability-对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像webserver和appserver那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。
对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1．数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。
因此数据库事务管理成了数据库高负载下一个沉重的负担。
2．数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。
并不要求这么高的实时性。
3．对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。
往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。
NoSQL是非关系型数据存储的广义定义。
它打破了长久以来关系型数据库与ACID理论大一统的局面。
NoSQL数据存储不需要固定的表结构，通常也不存在连接操作。
在大数据存取上具备关系型数据库无法比拟的性能优势。
该术语在2009年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。
而NoSQL存储就是为了实现这个需求。
Google的BigTable与Amazon的Dynamo是非常成功的商业NoSQL实现。
一些开源的NoSQL体系，如Facebook的Cassandra，Apache的HBase，也得到了广泛认同。
从这些NoSQL项目的名字上看不出什么相同之处：
Hadoop、Voldemort、Dynomite，还有其它很多。
1.2NoSQL数据库的特点
1.2.1NoSQL数据库的优点
易扩展性：
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。
数据之间无关系，这样就非常容易扩展。
也无形之间，在架构的层面上带来了可扩展的能力。
高性能：
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。
这得益于它的无关系性，数据库的结构简单。
一般MySQL使用QueryCache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。
而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
灵活性：
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。
而在关系数据库里，增删字段是一件非常麻烦的事情。
如果是非常大数据量的表，增加字段简直就是一个噩梦。
这点在大数据量的web2.0时代尤其明显。
高可用性：
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。
比如Cassandra，HBase模型，通过复制模型也能实现高可用。
1.2.2NoSQL数据库的缺点
目前，NoSQL还没有正式的官方支持。
此外，NoSQL数据库技术并未形成一定标准，各种产品层出不穷，内部混乱，各种项目还需时间来检验
1.3本文研究思路和结构安排
1.3.1本文研究思路和过程
本文主要对NoSQL数据库技术进行了介绍，重点对NoSQL数据库的应用做了学习和研究。
考虑到不同的应用领域需求，本文对常用的NoSQL数据库进行了分类汇总，学习并归纳了其主要特性。
1.3.2论文的结构安排
本文第一章介绍NoSQL数据库的基本概念以及背景知识；第二章重点研究NoSQL数据库的种类及应用。
第二章NoSQL数据库技术的应用
2.1几种常见的NoSQL数据库
MongoDB：
MongoDB是一个基于分布式文件存储的数据库。
由C++语言编写。
主要解决的是海量数据的访问效率问题，为WEB应用提供可扩展的高性能数据存储解决方案。
当数据量达到50GB以上的时候，MongoDB的数据库访问速度是MySQL的10倍以上。
MongoDB的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万-1.5万次读写请求。
MongoDB还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。
MongoDB也有一个Ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。
他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。
Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
所谓“面向集合”（Collenction-Orented），意思是数据被分组存储在数据集中，被称为一个集合（Collenction）。
每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。
集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema）。
模式自由（schema-free），意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。
如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。
存储在集合中的文档，被存储为键-值对的形式。
键用于唯一标识一个文档，为字符串类型，而值则可以是各中复杂的文件类型。
我们称这种存储形式为BSON（BinarySerializeddOcumentFormat）。
MongoDB服务端可运行在Linux、Windows或OSX平台，支持32位和64位应用，默认端口为27017。
推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。
CouchDB：
ApacheCouchDB是一个面向文档的数据库管理系统。
它提供以JSON作为数据格式的REST接口来对其进行操作，并可以通过视图来操纵文档的组织和呈现。
CouchDB是Apache基金会的顶级开源项目。
CouchDB是用Erlang开发的面向文档的数据库系统，其数据存储方式类似Lucene的Index文件格式。
CouchDB最大的意义在于它是一个面向Web应用的新一代存储系统，事实上，CouchDB的口号就是：
下一代的Web应用存储系统。
Hbase：
HBase是一个分布式的、面向列的开源数据库，该技术来源于Changetal所撰写的Google论文“Bigtable：
一个结构化数据的分布式存储系统”。
就像Bigtable利用了Google文件系统（FileSystem）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。
HBase是Apache的Hadoop项目的子项目。
HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.另一个不同的是HBase基于列的而不是基于行的模式。
HBase–HadoopDatabase，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。
HBase是GoogleBigtable的开源实现，类似GoogleBigtable利用GFS作为其文件存储系统，HBase利用HadoopHDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用HadoopMapReduce来处理HBase中的海量数据；GoogleBigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。
Cassandra：
Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。
其主要功能比Dynomite（分布式的Key-Value存储系统）更丰富，但支持度却不如文档存储MongoDB（介于关系数据库和非关系数据库之间的开源产品，是非关系数据库当中功能最丰富，最像关系数据库的。
支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。
）Cassandra最初由Facebook开发，后转变成了开源项目。
它是一个网络社交云计算方面理想的数据库。
以Amazon专有的完全分布式的Dynamo为基础，结合了GoogleBigTable基于列族（ColumnFamily）的数据模型。
P2P去中心化的存储。
很多方面都可以称之为Dynamo2.0。
Hypertable：
Hypertable是一个开源、高性能、可伸缩的数据库，它采用与Google的Bigtable相似的模型。
在过去数年中，Google为在PC集群上运行的可伸缩计算基础设施设计建造了三个关键部分。
第一个关键的基础设施是GoogleFileSystem（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。
它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败。
第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协作，帮助处理收集到的海量数据。
第三个基础设施是Bigtable，它是传统数据库的替代。
Bigtable让你可以通过一些主键来组织海量数据，并实现高效的查询。
Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。
Redis：
redis是一个key-value存储系统。
和Memcached类似，它支持存储的value类型相对更多，包括string（字符串）、list（链表）、set（集合）和zset（有序集合）。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
在此基础上，redis支持各种不同方式的排序。
与memcached一样，为了保证效率，数据都是缓存在内存中。
区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave（主从）同步。
TokyoCabinet/TokyoTyant：
TokyoCabinet（TC）和TokyoTyrant（TT）的开发者是日本人MikioHirabayashi，主要用于日本最大的SNS网站mixi.jp。
TC出现的时间最早，现在已经是一个非常成熟的项目，也是Key-Value数据库领域最大的热点，现在广泛应用于网站。
TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4万~5万次读写操作。
TC除了支持Key-Value存储之外，还支持Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于Column的条件查询、分页查询和排序功能，基本上相当于支持单表的基础查询功能，所以可以简单地替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一。
有一个Ruby项目miyazakiresistance将TT的Hashtable的操作封装成和ActiveRecord一样的操作，用起来非常高效。
Flare：
TC是日本第一大SNS网站mixi.jp开发的，而Flare是日本第二大SNS网站green.jp开发的。
简单地说，Flare就是给TC添加了scale（可扩展）功能。
它替换了TT部分，自己另外给TC写了网络服务器。
Flare的主要特点就是支持scale能力，它在网络服务端之前添加了一个NodeServer，用来管理后端的多个服务器节点，因此可以动态添加数据库服务节点、删除服务器节点，也支持Failover。
如果你的使用场景必须让TC可以scale，那么可以考虑Flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。
BerkeleyDB：
BerkeleyDB（DB）是一个高性能的，嵌入数据库编程库，和C语言，C++，Java，Perl，Python，PHP，Tcl以及其他很多语言都有绑定。
BerkeleyDB可以保存任意类型的键/值对，而且可以为一个键保存多个数据。
BerkeleyDB可以支持数千的并发线程同时操作数据库，支持最大256TB的数据，广泛 用于各种操作系统包括大多数Unix类操作系统和Windows操作系统以及实时操作系统。
BerkeleyDB最初开发的目的是以新的HASH访问算法来代替旧的hsearch函数和大量的dbm实现（如AT&T的dbm，Berkeley的ndbm，GNU项目的gdbm），BerkeleyDB的第一个发行版在1991年出现，当时还包含了B+树数据访问算法。
在1992年，BSDUNIX第4.4发行版中包含了BerkeleyDB1.85版。
基本上认为这是BerkeleyDB的第一个正式版。
在1996年中期，Sleepycat软件公司成立，提供对BerkeleyDB的商业支持。
在这以后，BerkeleyDB得到了广泛的应用，成为一款独树一帜的嵌入式数据库系统。
2006年Sleepycat公司被Oracle公司收购，BerkeleyDB成为Oracle数据库家族的一员，Sleepycat原有开发者继续在Oracle开发BerkeleyDB，Oracle继续原来的授权方式并且加大了对BerkeleyDB的开发力度，继续提升了BerkeleyDB在软件行业的声誉。
BerkeleyDB的当前最新发行版本是4.7.25。
Memlink：
Memlink是天涯社区开发的一个高性能、持久化、分布式的Key-list/queue数据引擎。
正如名称中的memlink所示，所有数据都建构在内存中，保证了系统的高性能（大约是redis几倍），同时使用了redo-log技术保证数据的持久化。
Memlink还支持主从复制、读写分离、List过滤操作等功能。
与Memcached不同的是，它的value是一个list/queue。
并且提供了诸如持久化，分布式的功能。
听起来有点像Redis，但它号称比Redis更好，在很多Redis做得还不好的地方进行了改进和完善。
提供的客户端开发包包括 c,python,php,java四种语言。
Versant：
VersantObjectDatabase（V/OD）提供强大的数据管理，面向C++,Javaor.NET的对象模型，支持大并发和大规模数据集合。
Versant对象数据库是一个对象数据库管理系统（ODBMS：
ObjectDatabaseManagementSystem）。
它主要被用在复杂的、分布式的和异构的环境中，用来减少开发量和提高性能。
尤其当程序是使用Java和（或）C＋＋语言编写的时候，尤其有用。
它是一个完整的，电子基础设施软件，简化了事务的构建和部署的分布式应用程序。
作为一个卓越的数据库产品，VersantODBMS在设计时的目标就是为了满足客户在异类处理平台和企业级信息系统中对于高性能、可量测性、可靠性和兼容性方面的需求。
Versant对象数据库已经在为企业业务应用提供可靠性、完整性和高性能方面获得了建树，VersantODBMS所表现出的高效的多线程架构、internalparallelism、平稳的Client－Server结构和高效的查询优化，都体现了其非常卓越的性能和可扩展性。
Versant对象数据库包括VersantODBMS，C++和Java语言接口，XML工具包和异步复制框架。
2.2关于MongoDB的实际操作
新建一个应用，其中新建一个docs.py文件，代码如下：
frommongoengineimport*
connect（'test'）
classUser（Document）:
username=StringField（required=True）
website=URLField（）
tags=ListField（StringField（max_length=16））
然后编辑views.py文件：
fromdjango.httpimportHttpResponse
from.importdoc
升级会员 