阿里云数据库技术分析

前言

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

HiTSDB

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

(更多…)

MySQL XA事务

2PC事务

2pc事务即通常所说的两阶段提交事务,全称Two Phase Commitment Protocol,主要为了解决在分布式部署的情况下,所有节点间数据一致性问题。在分布式部署的情况下,事务的提交会变得相对比较复杂,因为多个节点的存在,可能存在部分节点提交失败的情况,这个时候需要保证数据一致性的话,需要回滚那些能够提交的节点上的事务,总而言之,在分布式提交时,只要发生一个节点提交失败,则所有的节点都不能提交,只有当所有节点都能提交时,整个2pc事务才允许被提交。那么,怎样来保证所有的分布式节点都可以提交?其实,2pc事务的提交被分成两个阶段:第一阶段:prepare,第二阶段:commit/rollback。第一阶段的prepare只是用来询问每个节点事务是否能提交,只有当得到所有节点的“许可”的情况下,第二阶段的commit才能进行,否则就rollback。

(更多…)

MySQL基本概念——DoubleWrite

【背景】

前几天跟人聊起基于共享存储的MySQL,要保证Slave也能读数据,在主出现故障时能快速切换。由于MySQL上的数据刷盘是异步的,Slave读数据可能读取到的页是正在变更中的,这个能否有解决方法?第一个反应想到的是类似于DoubleWrite的结构,先开辟一块空间,把整个提交事务的数据先写到这块空间上,然后再拷贝到存储上,这种方式的确能实现类似需求,但是有几个问题:

  1. 事务不能过大,不然开辟的空间大小不好确定
  2. 主上提交的事务可能需要过段时间才能被从上读取,延迟过高。

其实这个需求有个很好的参考点,ORACLE的RAC基本就是这个套路,排除共享存储的实现,MySQL端需要做的,估计就只有实现Redo的复制和在Slave内存中的重放,当然也要禁掉Slave的刷盘行为。Redo复制,这个大厂基本都已经搞了,aliSQL在Percona大会上就讲过他们的物理复制,Aurora的关键点技术也是基于底层Redo的复制,现在就等MySQL官方版本什么时候放出来了。

(更多…)

MySQL MVCC实现

数据多版本(MVCC)是MySQL实现高性能的一个主要的一个主要方式,通过对普通的SELECT不加锁,直接利用MVCC读取指版本的值,避免了对数据重复加锁的过程,今天我们就用最简单的方式,来分析下MVCC具体的原理,先解释几个概念:

隐藏列

在分析MVCC原理之前,先看下InnoDB中数据行的结构:

row

在InnoDB中,每一行都有2个隐藏列DATA_TRX_ID和DATA_ROLL_PTR(如果没有定义主键,则还有个隐藏主键列):

  1. DATA_TRX_ID表示最近修改该行数据的事务ID
  2. DATA_ROLL_PTR则表示指向该行回滚段的指针,该行上所有旧的版本,在undo中都通过链表的形式组织,而该值,正式指向undo中该行的历史记录链表

整个MVCC的关键就是通过DATA_TRX_ID和DATA_ROLL_PTR这两个隐藏列来实现的。

(更多…)

MySQL异常锁冲突一例

背景

MySQL版本:5.7, 隔离级别:RR

测试表结构:

CREATE TABLE `sbtest1` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`k` int(11) NOT NULL DEFAULT ‘0’,

`c` char(120) NOT NULL DEFAULT ”,

`pad` char(60) NOT NULL DEFAULT ”,

PRIMARY KEY (`id`),

) ENGINE=InnoDB

标准的sysbench测试表,由于二级索引跟本次分析无关,所以没有创建。

整个表大概有50w行记录,表中的数据记录如下:

id k c pad
100 250731 xxx xxx
101 251240 xxx xxx
150 249472 xxx xxx
151 251323 xxx xxx

(更多…)

InnoDB recovery详细流程

InnoDB如果发生意外宕机了,数据会丢么?对于这个问题,稍微了解一点MySQL知识的人,都会斩钉截铁的回答:不会!为什么?他们也会毫不犹豫的说:因为有重做日志(redo log),数据可以通过redo log进行恢复。回答得很好,那么InnoDB怎样通过redo log进行数据的恢复的,具体的流程是怎样的?估计能说清楚这个问题的人剩的不多了,更深入一点:除了redo log,InnoDB在恢复过程中,还需要其他信息么?比如是否需要binlog参与?undo日志在恢复过程中又会起到什么作用?到这里,可能很多人会变得疑惑起来:数据恢复跟undo有半毛钱的关系?
其实,InnoDB的数据恢复是一个很复杂的过程,在其恢复过程中,需要redo log、binlog、undo log等参与,这里把InnoDB的恢复过程主要划分为两个阶段,第一阶段主要依赖于redo log的恢复,而第二阶段,恰恰需要binlog和undo log的共同参与,接下来,我们来具体了解下整个恢复的过程。
第一阶段
第一阶段,数据库启动后,InnoDB会通过redo log找到最近一次checkpoint的位置,然后根据checkpoint相对应的LSN开始,获取需要重做的日志,接着解析获取的日志并且保存到一个哈希表中,最后通过遍历哈希表中的redo log信息,读取相关页进行恢复。
InnoDB的checkpoint信息保存在日志文件中,即ib_logfile0的开始2048个字节中,checkpoint有两个,交替更新,checkpoint与日志文件的关系如下图:
1
checkpoint位置

(更多…)

HBase原理和设计

简介

HBase —— Hadoop Database的简称,Google BigTable的另一种开源实现方式,从问世之初,就为了解决用大量廉价的机器高速存取海量数据、实现数据分布式存储提供可靠的方案。从功能上来讲,HBase不折不扣是一个数据库,与我们熟悉的Oracle、MySQL、MSSQL等一样,对外提供数据的存储和读取服务。而从应用的角度来说,HBase与一般的数据库又有所区别,HBase本身的存取接口相当简单,不支持复杂的数据存取,更不支持SQL等结构化的查询语言;HBase也没有除了rowkey以外的索引,所有的数据分布和查询都依赖rowkey。所以,HBase在表的设计上会有很严格的要求。架构上,HBase是分布式数据库的典范,这点比较像MongoDB的sharding模式,能根据键值的大小,把数据分布到不同的存储节点上,MongoDB根据configserver来定位数据落在哪个分区上,HBase通过访问Zookeeper来获取-ROOT-表所在地址,通过-ROOT-表得到相应.META.表信息,从而获取数据存储的region位置。

架构

上面提到,HBase是一个分布式的架构,除去底层存储的HDFS外,HBase本身从功能上可以分为三块:Zookeeper群、Master群和RegionServer群。

  • Zookeeper群:HBase集群中不可缺少的重要部分,主要用于存储Master地址、协调Master和RegionServer等上下线、存储临时数据等等。
  • Master群:Master主要是做一些管理操作,如:region的分配,手动管理操作下发等等,一般数据的读写操作并不需要经过Master集群,所以Master一般不需要很高的配置即可。
  • RegionServer群:RegionServer群是真正数据存储的地方,每个RegionServer由若干个region组成,而一个region维护了一定区间rowkey值的数据,整个结构如下图:

hbase

HBase结构图

(更多…)