中文    English
当前位置: 本站首页 » 开放交流 » Geocafe » 正文

【GeoScience Café】从RocksDB到NewSQL-商业数据库的发展趋势

发布日期:2017-05-12 18:12:16 阅读次数:[4461]次 作者:

核心提示:随着互联网时代的到来,数据呈爆炸式增长,数据存储面临巨大挑战。各大互联网公司业务场景愈加复杂,数据库技术发展迅速,工程师们不再将眼光局限于Oracle、MySQL、MongoDB等耳熟能详的数据库上。本期嘉宾从原理和架构上介绍了最近大火的Facebook开源嵌入式K-V数据库引擎RocksDB,并从NewSQL的概念切入,分析商用数据库技术的发展趋势,最后还与听众互动交流,分享求职经验及阿里巴巴实习经历。

文字:戴佩玉  摄影:许慧琳 陈必武  摄像:陈清祥 主持:戴佩玉

>>>人物名片

王德浩,测绘遥感信息工程国家重点实验室2014级硕士,对RocksDB、MongoDB源码有较深入的研究。在阿里巴巴数据库团队实习期间,定位并修复了一个RocksDB深层次的bug,提交给Facebook官方,为RocksJava增加singleDelete接口。

>>>报告现场

5月5日,王德浩师兄做客GeoScienceCafé第160期学术交流活动,从RocksDB和NewSQL出发,介绍了商用数据库的发展趋势。

本次报告分四个部分。首先嘉宾引入RocksDB的基本概念;第二部分详解RocksDB架构;第三部分,比较RocksDB作为存储引擎与InnoDB的优劣势;最后对NewSQL以TiDB为例进行简要的介绍。

什么是RocksDB

首先,王德浩介绍了RocksDB的基本概念。RocksDB是一个由Facebook开发的开源的K-V存储引擎,根据Google BigTabel团队开发的LevelDB改进得到;不同于MongoDB、Orcal、MySQL等服务式数据库需要先开一个进程作为服务,通过网络进行访问,RocksDB是一个基于LSM-Tree的嵌入式数据库,直接在进程中调用API进行数据访问,对Flash存储友好,也可用于RAM或磁盘的存储,本质上是一个C++的库,支持Java和Python调用。

其次,嘉宾展示了RocksDB API以及代码示例(图1-2)。它是一个简单的KV存储,主要有插入、查询、删除、遍历、事务、多写集成等操作;代码示例中,直接利用DB::open打开文件夹,此时的数据库为文件夹下的文件,无需专门启动服务,让大家更直观地理解嵌入式数据库。

 

图1 RocksDBAPI示例

图2 RocksDB代码示例

之后,王德浩从不同角度给大家介绍了几种简单应用RocksDB的场景。首先,RocksDB可以用作客户端信息的缓存,管理本地消息。其次,利用RocksDB进行服务器的本地缓存,作用类似redis等内存数据库,能在内存有限的情况下提供较好的写入和查询性能,支持持久化。第三,服务器间的消息中转,分布式处理涉及大量信息在服务器间传递,利用RocksDB在服务器中暂时存储,比直接存储于文件速度快,查询管理效率高。第四,在很多场景下,可以直接利用RocksDB替代写文件。

接下来,嘉宾分析了使用嵌入式数据库的原因。图3展示了应用访问数据库时各个操作的耗时,对于一般数据库,例如MySQL,除了访问磁盘,还需要通过网络协议调取数据,这个过程所占时间比例很大。在存储量小,单一客户端的情况下,这种数据库不太适用,若使用RocksDB,嵌入式的特性使其能够直接调用数据,时间效率和性能都会提高。

图3 访问数据库操作耗时示意图

RocksDB还可作为存储引擎,嵌入MySQL、Yahoo Sherpa、MongoDB等能够提供服务的数据库中。以MySQL为例,它是一个高度分层的结构,包括提供服务的service层,专门管理数据的多种类型的存储引擎层,默认存储引擎为InnoDB,Facebook尝试将RocksDB作为存储引擎嵌入到MySQL中(即Facebook MyRocks),用户可以在MySQL中使用RocksDB。

RocksDB架构

目前,大部分数据库都基于B+树,而RocksDB采用LSM-Tree(Log Structure Merge Tree),是一个分层架构,由两个或两个以上存储数据的结构组成。图4展示了一个最简单的LSM-Tree结构,由两个部件构成:一个部件常驻内存,称为C0,通常为任何方便键值查找的数据结构(如哈希表、跳转表、AVL树等);另一个部件常驻硬盘中,称为C1,用于持久化存储数据。LSM-tree将对数据的修改增量保存在内存,达到一定阈值后,将这些修改批量写入磁盘,但在读取时,需要合并磁盘和内存中的数据。LSM-tree写操作是批量顺序写,效率很高。但读操作由于磁盘中的每层有包含目标的可能性,不得不访问较多文件。

图4简单LSM-Tree示意图

基于LSM-Tree的RocksDB主要由三个部件组成:memtable、sstfile和logfile。其中memtable位于内存,sstfile与logfile持久化在硬盘。Logfile记录日志,用于崩溃恢复和事务。Sstfile是LSM-Tree的磁盘部分,每个文件存储的数据都按key值顺序排列,便于二分查找。新的数据插入时,首先按照操作顺序写logfile,logfile顺序写入磁盘。接着将数据插入memtable,写满后形成一个sstfile顺序写入磁盘,删除此时相应的logfile。

图5 RocksDB基于LSM-Tree的结构示意图

RocksDB的LSM-Tree在磁盘呈金字塔结构排列,从memtable刷入磁盘中的文件为第0层,当第0层数据累积到阈值后,下沉到第一层,随着新数据不断插入,老数据不断下沉。为了保证金字塔结构稳定,后台进行Compaction。Compaction的作用在于让旧的文件和数据不断下沉,新的数据占据上层的位置,清理已经被新插入的数据所覆盖的过时无用的数据,节约磁盘空间。

RocksDB的优劣势

MySQL默认存储引擎为基于B+树的InnoDB,各方面性能稳定,嘉宾将RocksDB作为MySQL的存储引擎与它进行了对比,分析优劣。

首先,在写性能方面,由于用户的写请求通常是随机的,B+树所有数据存储于叶子节点,随机写入的数据可能位于不同的叶子节点,在最坏的情况下,写入N条数据,需要写N次磁盘。而LSM-Tree将随机写操作积累在内存中,最后一次性刷入磁盘,写操作效率高。因此,在有大量随机写的应用场景下,选择RocksDB作为MySQL的存储引擎比InnoDB合适。

图6 RocksDB与InnoDB写操作性能比较

B+树的叶子节点会由于插入新数据,不断分裂合并,空间利用不充分,并且InnoDB在压缩之后,压缩页占固定大小的空间,而RocksDB按文件存储,不存在此问题。因此,在如今大数据时代,对于相同的数据量,RocksDB作为存储引擎的在空间利用率上更胜一筹。

图7 RocksDB与InnoDB数据量对比

写放大是指观察到磁盘数据的写入量与实际数据写入量的比值。B+树中,修改叶子节点中的一条数据会将整个节点写入磁盘,写放大系数为sizeof(leaf page)/sizeof(row)。RocksDB中,即使在compaction时会将sst文件读取到内存,合并清理后再写入磁盘,或多或少存在写放大问题,但相对于B+树要小很多。写放大过多,会对SSD擦写过多,缩短其使用寿命,造成成本的增加。

图8 RocksDB与InnoDB写放大实验对比

但在查询时(尤其是范围查询),B+树效率很高,而RocksDB在最坏情况下需要在内存,Level0,Level1,…每层中查找目标结果,效率低下,这是RocksDB相比于InnoDB的劣势。

因此,RocksDB具有更强的连续写入性能,对于写入较多的事务具有更高的吞吐量;写放大小,更适合SSD;压缩率高,节省磁盘空间;但范围查询性能不及InnoDB,对于读取频繁的业务,InnoDB更优。

NewSQL

随着互联网时代的到来,数据量激增,分布式存储系统蓬勃发展, NoSQL数据库登上历史的舞台,它们性能强劲、可扩展性强、部署简单,但舍弃了SQL语言支持和数据的一致性。MySQL、Oracle、PostgreSQL等关系数据库虽然功能强大,但很难扩展,尽管有分片技术,但不支持分布式事务以及cross-nodejoin连接。NewSQL是一类新式关系型数据库管理系统,针对OLTP实现读-写工作负载,追求提供和NoSQL系统相同的扩展性能,且仍然保持传统数据库支持的ACID特性,让海量数据处理更加容易。

最后,嘉宾给大家介绍了一款国产NewSQL数据库TiDB。TiDB主要由三个部分组成:TiDB Server、PD Server和TiKV Server。TiDB Server负责接收SQL请求,处理SQL相关的逻辑,并通过PD找到存储计算所需数据的TiKV地址,与TiKV交互获取数据,返回结果。Placement Driver(简称PD)是整个集群的管理模块,存储集群的元信息,对TiKV集群进行调度和负载均衡,分配全局唯一且递增的事务ID。TiKV Server基于RocksDB实现负责存储数据,从外部看,TiKV是一个分布式的提供事务的Key-Value存储引擎,存储数据的基本单位是Region,每个Region负责存储一个KeyRange数据,每个TiKV节点负责多个Region。TiKV使用Raft协议做复制,保持数据一致性。

 

图9 TiDB架构图

TiDB在原有的关系型数据库的基础上增加了两个核心特性。首先,无限水平扩展,包括计算能力和存储能力两方面。TiDB Server负责处理SQL请求,随业务增长,可以简单添加TiDB Server节点,提高整体的处理能力,提供更高的吞吐。TiKV负责存储数据,随着数据量的增长,可以部署更多的TiKVServer节点解决数据Scale的问题。其次,高可用性,TiDB/TiKV/PD这三个组件都能容忍部分实例失效,不影响整个集群的可用性。

 

>>>互动交流

观众A:RocksDB,如果使用Jdbc_0,是否也需要访问网络?

嘉宾:RocksDB作为嵌入式数据库目前不支持Jdbc,不需要通过网络,它提供Java的接口,相当于将JAVA用JNI转换成C++请求,直接调用Java API即可。但MyRocks支持JDBC连接,因为MyRocks上层就是MySQL Server。

观众B:做compaction的时候,每一层更新下沉的都是上一层最旧的数据开始吗?

嘉宾:不是,由于它在每一层中已经被重新排序了,新旧已经没有了。它的触发条件可以有很多,有的时候是delete最多的一个,因为所有的删除工作都是在compaction时做的。有的时候也可能是最大的一个。

观众C:RocksDB这个数据库沉降到最底层已经达到了100G,师兄您讲的这个原理有点类似Hbase,Hbase的底层文件存储在Hadoop中,这边的数据是存储在哪里呢?

嘉宾:可以存储在本地文件系统,也可以存储在分布式文件系统上,而且一般来说RocksDB用于轻量级的应用,不像Hbase,所以他的存储不是很大。

观众D师兄可以分享下去年实习、求职中的准备和面试经验吗?

嘉宾:首先得掌握基本的数据结构和算法,其次,精通某一门语言,同时,对计算机网络,数据库,SQL语句、操作系统等都要有广泛的涉猎,其他根据自己的求职方向进行。在笔试和面试中,最难的是手写代码的能力,可以不断进行训练,熟能生巧。

图10 嘉宾给大家作报告

 

图11 观众认真聆听报告

图12 观众与嘉宾互动交流

图13 嘉宾(左四)与GeoScience Café团队成员合影留念

(编辑:肖珊)

GeoScienceCafé以“谈笑间成就梦想”为口号,采取最自由的交流方式,每期邀请1-4位报告人,针对自己正在进行的研究展开报告。每周五晚7:30,在测绘遥感信息工程国家重点实验室四楼休闲厅举行当期活动。报告内容不仅涉及一切与测绘有关的学科内容及学术方法,如测绘基础学科、地理信息系统、摄影测量与遥感、全球定位系统、激光雷达技术、信号处理,还包括地理信息科学以外的话题,如法律和艺术等。让任何感兴趣的人——不仅是地理信息相关专业的师生,还包括其他专业的师生,甚至是文科生——都可以听取报告,并当场向主讲嘉宾提问或者会后与其交流。

更多精彩内容(报告PPT、新闻稿及下期活动消息等)敬请关注GeoscienceCafé群(QQ群号:532362856),微信公众号:GeoScienceCafe

欢迎扫描二维码:

 

 

 

 

版权所有:测绘遥感信息工程国家重点实验室   
联系地址: 中国·武汉市珞瑜路129号   邮编: 430079   E-mail:liesmars@whu.edu.cn
Tel/Fax:027-68778969(办公室) 027-68778229(国际交流办公室)027-68778525(研究生管理办公室)