大数据趋势下的RD与NoSQL融合
作者：储智广 滕征岑 张志伟 王博
来源：《石油知识》 2016年第2期
redis是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过渡的一个最好选择。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论