阿里云数据库技术分析

前言

昨天(2017-08-24)阿里云数据库技术峰会在网上直播,作为一个数据库从业者,对自身领域内的新东西还是比较敏感,本着学习的态度认真观看了下大部分内容,总的感觉没有特别的惊喜,基本上都是一些内部(或外部)已经成熟的技术或服务,只不过这次被阿里云搬到了云服务上对外提供,逐一分析下各个产品:

HiTSDB

HiTSDB是阿里云一款分布式时序数据库,主要用于海量时序数据的存储,当前市面上成熟的时序数据库其实很多,比如:Druid、OpenTSDB、InfluxDB等等,都是当前比较主流的时序型数据库,个人认为时序数据库的主要特点在于:数据产生都带时间戳,数据量非常庞大,但一般数据的时效性比较明显,怎么理解?就是说一般需求的数据都集中在最近1~2周内,对于历史数据,基本上都只是非精确的需求,比如像一般的报警平台,基本上报警处理都在最近的1天内,很少会追溯到1周前的报警信息,所以一般处理上对于多天前的数据基本上可以聚合处理,基本上每个时序数据库都有历史数据聚合功能。
回过头来看下HiTSDB,从PPT上看,HiTSDB的原型就是OpenTSDB,相比于OpenTSDB,HiTSDB在此基础上增加了倒排索引和不同压缩方式。不可否认,倒排索引能使HiTSDB具有多维度组合查询能力,但这个怎么看都像是抄Druid的,整个从技术栈上来看没有多大新意。

HTAP

HTAP是最近冒出来的新名词,以前的平台OLTP与OLAP都分得比较清楚,一个数据库,要么是TP型的,如:MySQL、PostgreSQL;要么是AP型的,像Hive、Spark、Impala,HTAP宣称是一种混合模型,即所谓的Hybrid,是一种OLTP + OLAP集成方案。
在个人印象中,OLTP与OLAP差异还是比较大的,首先存储上OLTP基本上是行存,OLAP则大多数偏向列存(SAP HANA是个例外),因为OLAP很多情况下需要读取指定列的全部数据,列存有天然的优势。那么阿里云的HTAP的数据怎么存?
阿里云的HTAP即HybridDB for MySQL,也就是原来的PetaData,实现上用TokuDB作为MySQL的存储引擎,TokuDB相比于InnoDB在写入的数据量上有很大的提升,基本上数据存储量可以是InnoDB的5~6倍,但是这都以牺牲性能为代价。个人看来,其实还有更好的选择 —— RocksDB,云栖社区有一篇博文专门比较了InnoDB、TokuDB、RocksDB三者在不同场景下的性能,从结论上来说,基本上TokuDB被RocksDB完爆,在基本相同的压缩比下,RocksDB仍然维持了与InnoDB相近的读写性能,而TokuDB…..
说完了引擎层,再分析下HTAP的上层,HTAP基本上踢掉了DRDS这种中间件模式,而重新实现了一种类MPP的模式,中间件与MPP目前是单机数据库比较常用的两种扩展模式,个人认为MPP相比中间件更有优势,因为中间件基本对数据库是没有侵入性的,也就造就了中间件对很多查询的优化显得很力不从心;相反,MPP与底层结合的更为紧密,可以实现很多特定的优化。
从上面的分析基本可以得出:HTAP基本上以一种MPP的形式,通过TokuDB作为存储引擎来实现。那么OLAP怎么办?方式简单粗暴,直接用Flink在上面进行计算…,又不禁让我想起另外一家厂商:pingcap,TiDB + TiSpark,同样的行存,同样的类MPP架构,同样的号称Hybrid,当然方式也同样粗暴,只是底层用了RocksDB,计算引擎换成了Spark…
另:阿里云还有另外一种HybridDB for postgreSQL的混合型数据库,原型为GreenPlum。

DTS

DTS即数据传输服务,通过DTS可以实现不同数据库,不同数据中心之间的数据同步。阿里DTS只是一个外部服务名称,对外部用户开放,在内部被称为DRC,DTS支持Oracle、MySQL、PostgreSQL、MSSQL等多种不同的数据库之间数据的同步,这里的同步是可以支持异构数据的,不仅限于相同数据库之间的数据传输,也就是说可以把Oracle的数据同步到MySQL或者其他支持的数据库,DTS也支持更新缓存(如redis等),导数据到计算平台等等。当然另外一个功能可以在不同的数据中心之间传输数据,延迟基本在1s以内,这为同城跨机房、异地多活提供了技术保障。

HBase

HBase云服务基本上就比较简单,没有什么标新立异的地方,讲了些HBase的场景,基本上跟我们的类似,他们HBase上架了Phoenix来提供二级索引和SQL支持,这个我们内部目前还没有,以前是觉得Phoenix还不够稳定,现在人家敢拿出来在共有云上用,我们应该也可以尝试下。二级索引不能太多,最好不要超过2个,这个也可以理解,毕竟数据量会有很大增长。
至于事务,人家明确说HBase不会支持事务,事务应该交给数据库,这个怎么说,毕竟目前就Yahoo的omid号称支持事务,到底怎么个玩法,其实大家都没底。
最后说后续打算把HBase放公网上去玩,这个风险还是挺大,认证和授权机制需要完善。而其中提到了多活这种需求,HBase的多活需求相对于数据库没有很强烈,Replica出来这么久了也没见几个人真正的用。

DMS

数据管理平台,更类似于一个运维平台,这个目前不是我的研究范围,pass。

PolarDB

在InnoSQL的早期版本(大概2013年)我就想做InnoDB基于Redo的复制,刚接触Hadoop和EMR的时候(2014年)就在想如果把MySQL的底层文件系统换成HDFS会怎么样?性能和实现上的复杂度先不说,至少物理复制和共享存储这两个点我都想到了,只是还没有把这两个东东融合起来的想法。
回来看下PolarDB,初一看整个结构跟AWS的Aurora还挺类似,AWS在2014年底发布了Aurora,PolarDB在2017年中才准备推出,中间差了2年半。Aurora把数据页的恢复直接丢给了底层存储去做,换句话说Aurora的存储层是定制的,不仅要提供数据存储,还需要实现把Redo log apply到数据页的过程,不是一个通用的存储层。而PolarDB的存储与Aurora不同,底层应该是一个通用的存储,依赖RDMA高速网络和Parallel-Raft实现底层数据多副本存储。反复听到一个词:7微秒,一次RTT做到惊人的7微秒,还要本地磁盘干啥~~~

发表评论

电子邮件地址不会被公开。 必填项已用*标注