毕业论文网
该文是关于大数据论文范文，为你的论文写作提供相关论文资料参考。
大数据趋势下的RD和NoSQL融合
储智广 滕征岑 张志伟 王博
（北京中油瑞飞信息技术有限责任公司北京100007）
摘 要：随着互联网技术的飞速发展,对数据存储技术提出了更高的需求.本文结合NoSQL应用案例,分析了关系型数据库和非关系型数据库两大数据存储类型,对企业未来应对大数据存储选择问题提出新的思路和看法.
关键词：大数据；数据存储；关系型数据库；RD；NoSQL
随着互联网的飞速发展,对数据存储技术提出了更高的要求.虽然关系型数据库(RD)在数据存储方面有较大优势,但在低延迟的读写速度、支持海量的数据流量、大规模集群的管理、降低成本等方面,已经很难满足企业的实际需求,非关系型数据库 NoSQL)应运而生.
NoSQL非常关注对数据高并发地读写和对海量数据的存储等,与关系型数据库相比,在架构和数据模型方面做了“减法”,而在扩展和并发等方面做了“加法”.
1为什么选择NoSQL数据库
1.1 RD的不足
(1)大数据量的写入处理.在数据读入方面,由复制产生的主从模式可以通过增加从数据库简单地实现规模化,但在数据写入方面则没这么简单.例如：数据的写入规模化可以考虑把主数据库从一台增加到两台,作为互相关联复制的二元主数据库,这样可以减少每台主数据库的负荷,但更新处理会发生冲突,可能造成数据的不一致,因此需要把每个表的请求分别分配给合适的主数据库来处理,这样就使问题变得复杂化.
(2)为有数据更新的表做索引或表结构变更.使用关系型数据库时,为了加快查询速度需要创建索引,增加必要的字段就一定要改变表结构,这需要对表进行共享锁定.共享锁定期间无法进行数据的变更（更新、插入、删除等）.如果共享锁定较长,可造成数据长时间无法更新.
(3)字段不固定时的应用.如果字段不固定,利用关系型数据库也是比较困难的.有人用“需要的时候增加字段”的方法,但是在实际中不易实现.也有人采取预留大量字段的方法,但时间久了很容易被忘记.
1.2 NoSQL的优势
(1)易于数据的分散.关系型数据库是以JOIN为前提（即各个数据之间存在一定的关联）,进行JOIN处理时不得不把数据存储在同一个服务器中,这不利于数据的分散.相反,NoSQL是不支持JOIN处理的,各个数据都是独立设计的,很容易分散到多个服务器或者PC上,减少了每台服务器的数据量.即使需要进行大量数据的写入操作,处理起来也很容易.同理,数据的读取操作也比较容易实现.
(2)提升性能和增大规模.想要服务器轻松处理更大量的数据,只有两个选择：一是提升性能,二是增大规模（图1）.前者通过提高现行服务器自身的性能和配置来提高处理能力,不需要变更程序,但需要一定的费用.目前市场上购买性能翻倍的服务器,花费一般比原来高2倍,甚至可达5~10倍.后者就是使用更多廉价的服务器来提高处理能力,这样可以降低成本,但需要变更程序.
通过对程序进行变更来提升性能是可行的,但是在云技术时代,各种应用层出不穷,数据处理的瓶颈是关系型存储方式.这也是NoSQL出现的原因.
1.3 NoSQL的应用现状
NoSQL因互联网而生,故目前大部分应用在互联网企业中.现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等（表1）.
2 NoSQL典型产品分析
NoSQL在存储数据模型上遵循schema-free原则,目前主要有列式( Column)、文档型(Document)、键值对(Key-Value)、图型(Graph)等4类.根据不同的模型,NoSQL还可以分为不同种类的数据库（表2）.
根据市场上的应用情况和实际数据测试分析,对部分产品的特点进行了简单的整理.
Memcached：挥发性的键值存储；一般用作RD的缓存；存在数据丢失的可能,一般用来处理不需要持久保存的数据；用于需要定期清除数据时；使用Consistent Hashing算法（即一致性hash算法）来分散数据.
Tokyo Tyrant:持久的键值存储；用来处理需要持久保存、高速处理的数据；用于不需要定期清除数据时；使用Consistent Hashing算法来分配数据.
Redis:兼具Memcached和Tokyo Tyrant优势的键值存储；擅长处理数组类型的数据；可以高速处理时间序列的数据,易于处理集合运算；拥有很多可以进行原子处理的方法；使用Consistent Hashing算法来分散数据.
MongoDB:具有无需定义表结构的文档数据；通过BSON( Binary Serialized Document Format)形式可以保存和查询任何类型的数据；无法进行Join处理,但是可以通过嵌入来实现该功能；使用sharding（范围分割）算法来分散数据.
上述产品均具有非常快的处理速度.
3 NoSQL和RD的融合
3.1 NoSQL面临的挑战
NosoL数据库通过自身易扩展性、支持大数据、高性能、高可用性、低成本和灵活的数据模型等特点弥补了RD的一些不足.但是,NosoL数据库还存在以下不足：
(1)支持度低.大部分的NosoL系统都是开源项目,没有足够能力和支持资源,或者说没有类似于Oracle、Microsoft等大公司的信用支持.
(2)成熟度低.目前大部分NosoL产品还有大量的关键特性有待实现.
(3)零管理难以实现.NosoL的设计目标是提供零管理的解决方案,但此目标远远没有实现.目前的NosoL系统需要大量的技术进行升级和维护.
(4)尚不支持soL.soL是数据存储的工业标准,不支持soL将会使用户产生一定的学习和应用迁移成本,推广实施难度大.
NosoL与RD各有优缺点（表3）,如果双方可以融合或者汲取对方的优点,将是一个很有价值的发展方向.
3_2 RD数据NoSQL化典型案例分析
3.2.1 HandlerSocket
HandlerSocket是一个MySql的插件.通过这个插件可以直接跟MysoL后端的存储引擎做key-value式的交互,每秒查询率可以达到75W.
NosoL是为了弥补关系型数据的不足而开发的,而HandlerSocket却是完全不同的解决方案,它可以使关系型数据库本身具有NosoL的功能,有比memcached还要高的处理速度.由于数据库还是MysoL,只是读取数据有所不同,使用方便而且还有丰富的经验可循,一时间HandlerSocket成为NosoL的焦点.
3.2.2 HandlerSocket性能测试
前提是需要为MysoL安装插件、PHP（超文本预处理器）扩展.创建如下的表,然后向其插入20000条数据.
在读取数据部分,需要用user_id进行查询,因此事先要为user_id创建索引,其中InnoDB开启了索引功能（表5）.
可以看出,HandlerSocket的处理速度更快,与开启了索引功能的memcached相比有较大优势.
通过验证可以知道,HandlerSocket使用简单,有非常高的处理速度.虽然稳定性有待验证,但已经有公司开始使用它了.
3.3 RD与NoSOL市场融合趋势
InnoDB的性能已经足够好,并可以直接提供NosoL的功能.但HandlerSocket的出现,给人更多意外.它最大的优点就是可以共享MysoL的功能.
可能是受HandlerSocket启发,MysoL开始关注NosoL领域的应用,并在MysoL5.6 2版本开始增加了通过Memcached协议直接访问原生InnoDB API的功能.InnoDBwith Memcached是在提供MysoL服务的同一进程中提供Memcached服务,这与HandlerSocket的架构模式几乎一样.
因为MysoL Cluster提供了99.99%的高可用性,并提供了去中心化的无缝可扩展性,所以对于依赖key-value查询和写入的海量数据存储需求来说,MysoL Cluster withMemcached搭配是一个更好的选择.
4结语
网络资源爆炸式的增长,使得对NosoL的需求越来越大,已经有越来越多的公司和开发者投入到NosoL产品应用和研发中来.但由于自身成熟度低、不支持soL等因素,NosoL短期内不会替代soL.NosoL不会替代RD的原因有3个：传统行业的数据业务可以用Oracle rac等方案解决；现在很多网站只是离线应用NosoL,在要求强一致性的广告系统里依然采用RD,如阿里巴巴、新浪微博、腾讯等；根据CAP理论,NosoL选择的是CP、没有兼顾A,RD选择的是CA,扩展起来比较困难.如果NosoL为了弥补A而朝着A的方向发展,那么将出现一个新的关系型数据库.
正如市场上MysoL with HandlerSocket和InnoDB withMemcached的出现,RD扩展了NosoL的功能是响应了用户的实际需求.RD与NosoL的融合是未来很多数据库产品的一个趋势,也可以理解为RD向NosoL过渡的一个最好选择.
大数据论文范文结:
关于大数据方面的论文题目、论文提纲、大数据论文开题报告、文献综述、参考文献的相关大学硕士和本科毕业论文。
1、大数据时代论文
2、关于大数据的论文
3、大数据杂志
4、有关大数据的论文
5、健康大视野杂志