[Database] 解密OceanBase

博客首页 » Database 解密OceanBase

发布于 24 Nov 2015 14:47
标签 blog
OceanBase是阿里巴巴开发的一个数据库系统，支撑了双十一的关键业务，如支付和购物车、收藏夹。在2014年底，核心人员蒋志勇简介了OceanBase的特性。

26页PPT解密支撑支付宝交易的分布式数据库系统——OceanBase
http://www.36dsj.com/archives/20317

今年的淘宝双11交易额达到的惊人的571亿，在这些光鲜数据的背后，其实也是对淘宝数据库的极大考验。更值得一提的是，今年双11支付宝的支付峰值突破了每分钟285万笔，创下了新的纪录。如此高并发负载的交易量，让我们对幕后支撑的数据库技术OceanBase心生好奇。究竟OceanBase有哪些强大之处呢？

相信大家看完这篇文章就明白了。

2014中国大数据技术大会第二日下午大数据生态系统论坛上，阿里巴巴资深技术专家蒋志勇为大家详细介绍了OceanBase，演讲主题为《OceanBase，支撑支付宝交易的分布式数据库系统》。

OceanBase
蒋志勇表示，OceanBase是一个分布式关系数据库，也是第一个用于金融核心系统的非商业数据库。对比传统商业解决方案，它提供了很多互联网公司急需的特性：基于PC服务器，可在线水平扩展；无共享存储；性价比高于商业数据库。

蒋志勇还对比了互联网领域和传统业务中数据库不同特性的需求：

事务(ACID)：互联网 = 传统业务；

可用性：互联网 = 传统业务性能：

互联网 »传统业务；

性价比：互联网 »传统业务；

扩展性：互联网 »传统业务。

为了保证数据的完整性，在使用灰度升级之外，阿里还会对数据进行校验：磁盘读写，每条记录带64位checksum；网络传输，每个网络包带64位checksum；每个文件多副本(3~6)，每个文件都有64位checksum；修改增量多副本，带64位累积checksum；Redo log，每条都带checksum及对应于UpdateServer内存的checksum；每个表每个列都带64位checksum。

关于支付宝核心数据库 OceanBase的一些信息：

1、OceanBase是阿里巴巴自主研发支持海量数据的高性能分布式数据库系统。

2、比传统的关系数据库，谈及OceanBase的最大亮点，当属可自动扩展的特点，它不仅仅可以扩展到一个数据中心，乃至同城，在未来，OceanBase能成为跨地域多数据中心的全球数据库。当然，OceanBase还有一些特性，比如强一致性，能够自动容忍一台服务器甚至是整个数据中心故障，而不会丢失一条记录。值得强调的是，支付宝交易之所以会选择OceanBase而不是开源的MySQL，正是因为只有OceanBase能够做到完全不丢数据。

3、OceanBase内部会自动把数据切分为一个个比较小的分片，每台机器服务若干个分片，当某台服务器的分片成为热点时，会自动触发迁移操作，将分片从负载较高的服务器迁移出去，这样，就避免了“木桶效应”。这也是OceanBase的一个优势，无论双十一之前热点怎么变，OceanBase都可以很快把热点数据均衡到整个集群，而不是因为一两台服务器把整个集群压垮了。

4、OceanBase是真正的分布式关系数据库，不仅仅支持分布式，还支持SQL、事务、并发控制这样的关系数据库特性，用户使用起来和MySQL没有任何差别。

5、OceanBase的事务引擎面向内存设计的，它的特点就是快，而且避免了传统数据库的写入放大问题，这样，OceanBase的锁等待天生就要更少。另外，OceanBase还提出并第一个实现了提前解锁、排队等待等优化思想，这些思想后来也应用到集团MySQL数据库的patch中，成为阿里双十一应对热点问题的标配。

6、和MySQL的不同点在于，MySQL主备同步是有丢数据风险的，而OceanBase通过Paxos选举协议实现强一致性。无论是一台服务器，还是数据中心整体故障，OceanBase都能够自动恢复，而且做到完全不丢数据。OceanBase的这种做法和Google、Microsoft以及Amazon云存储系统的底层原理都是共通的。

支撑支付宝交易癿分布式关系数据库

内容

互联网应用对数据库的挑战
OceanBase的解决之道
小结

Why NOT 商业数据库？

Google
Facebook
Amazon
Tencent
Alibaba
ebay
Baidu
Yahoo
LinkedIn
Twitter

对数据库幵发性能癿挑战

传统应用

职员/柜员机
(几百,几千,几万)
操作数据库

互联网

网民/草根
(几十万/几百万)
操作数据库

对数据库扩展能力的挑战

传统应用

新建/扩建商场
数年/数月

互联网

2013.11.11
1700万人同时
在线

对数据库高可用的挑战
峰值支付每分钟285万笔(2014)
首小时支付达6283万笔(2014)

互联网需要癿数据库

高性能
高可扩展
高可用
低成本

关于OceanBase
一个分布式关系数据库
第一个用于金融核心系统癿非商业数据库
 基于PC服务器，可在线水平扩展
 无共享存储
 性价比高于商业数据库。

OceanBase 开发里程碑

2010.6
2011.2(v0.1) 淘宝收藏夹
2011.10(v0.2) 主从群
2012.4(v0.3) 数据报表，统计分析
2012.11(v0.4) SQL
2014.2(v0.5) 多群

OceanBase性能：如何超越

跟随先行者癿足迹去追赶并超越？
读( (磁盘随机读) )

✖机械磁盘随机读： 100~300次/秒 (IOPS)
✔固态盘 (SSD)随机读：几万次/秒 (IOPS)

写( (磁盘随机写) )

✖机械磁盘随机写： 100~300次/秒 (IOPS)
数据库写入放大：8KB块，每次修改 100B -> 80X
固态盘：写入放大 & 写入前先擦除

数据库应用实例

全国人口数据库

 14亿条记录
增删改：出生、死亡、迁移 ……

支付宝交易数据库

每笔交易一条或几条记录
增删改：创建、买家已付款、卖家已发货、退货退款 ……

支付宝账务库

每个人一条或几条记录
增删改：付款、收款、账户变更 ……

结论：记录总量大，而一天内增删改量占比很小。

数据库：总量大，增删改量少
 10亿笔写事务， 100 B/事务  100

OceanBase的解决之道

Query
|
V
Data = 基线数据(固态盘) + 修改增量(内存)

OceanBase架构

一个 Root Server - 总控中心

一个 Update Server - 修改增量

多组

MergeServer - 应用接口
ChunkServer - 基线数据

 修改增量( (增删改) )置于内存：无随机磁盘写、性能高
 单点写入：数据一致性好，性能&内存容量有瓶颈
 修改增量与基线数据跨服务器

修改增量一直在内存？

每日合并修改增量到基线

读写事务照常进行
|
V
Data = (基线数据 + 修改增量) + 新的修改增量

使用新旧基线数据，查询结果相同

每日合并的耗时
 一条记录修改，整个数据重写
 50 MB/s写入4 4 TB盘，需4 4 TB/ 50 MB= 80, , 000s s

降低每日合幵癿耗时
 数据分块( (例如2MB) )

易于扩展
 外部：一台虚拟大型机
 内部：多台 PC服务器组成
按需扩容，自动迁移数据
最大业务机群： 200+台

廉价硬件 + 实时故障恢复
水平扩展

多机群：更高可用性
3/5 > 2/3 > 2/2

服务器故障自动恢复

主库故障不丢数据
自动恢复(时间最长30s)

数据库灰度升级(1)
 2014.8.19- - 30，美国国务院签证数据库异常 (Oracle)
 2013.6.23，中国工商银行数据库异常( ( DB2)
 OceanBase升级 Step 1. . 切走一个库流量幵升级
 内置自动数据比对

数据库灰度升级(2)
 OceanBase升级 Step 2.逐步导入流量
 白名单、 1%、 2%、 5%……
 继续数据比对，出现异常立即回滚

数据校验
磁盘读写：每条记录带 64位 checksum
网络传输：每个网络包带 64位 checksum
每个文件多副本 (3~6)：每个文件都有 64位
checksum
修改增量多副本：带 64位累积 checksum
 Redo log：每条都带 checksum及对应于
UpdateServer内存癿 checksum
每个表每个列都带 64位