1.
LAMP人 主题分享交流会
www.LAMPER.cn
QQ群：3330312
http://weibo.com/lampercn

2.
LAMP人 主题分享交流会
www.LAMPER.cn
QQ群：3330312
http://weibo.com/lampercn

3.
OceanBase
千亿级海量数据库
2011.5
日照：rizhao.ych@taobao.com
3

4.
Agenda
 存储需求与现有方案
 Oceanbase技术方案
 收藏夹应用案例
 系统展望
4

5.
在线存储需求
 数据库在线存储需求
 数据规模：百TB级，百台机器
 OLTP：几十万QPS，几万TPS
 OLAP：支持千万级记录实时计算
 支持事务
 强一致性 (vs. 弱一致性、最终一致性)
 可用性：5个9
 运维简单性：不再拆库，自动扩容
5

6.
现有存储方案对照
Bigtable
HBase
万亿记录 数 Megastore
据
Dynamo (十PB) 规
模
Cassandra OceanBase
千亿记录
(百TB)
十亿记录
(TB)
RDBMS
千万记录 事务与数据一致性
(百GB)
最终一致 单行事务 跨行跨表事务
 NoSQL系统
 数据容量大、可扩展性好、容错能力强
 没有跨行跨表事务、数据一致性弱 6

7.
OceanBase
 始于2010年5月
 海量数据存储特点的进一步分析
 数据量大但修改量较小，一千亿 * 1%* 100B = 100G
 区分最新修改的增量数据和以前的基准数据？
 OceanBase = RDBMS + 云存储
 增量数据(增删改操作)：单机之内存+SSD
 基准数据：静态B+树，多机
 数据读取 ：基准数据+增量数据
 数据写入 ：增量数据
 事务：集中化写事务+分布式读事务
7

8.
OceanBase系统架构
RootServer/ RootServer/
UpdateServer UpdateServer
(主) (备)
JavaClient
ChunkServer ChunkServer ChunkServer ChunkServer
 主控服务器RootServer：主+备，数据定位/全局Schema/机器管理…
 增量数据服务器UpdateServer：主+备，实时修改(内存+SSD)
 基准数据服务器ChunkServer：多台，B+树叶子节点 (磁盘或SSD)
 增量数据定期合幵到基准数据中，从而分散到多台ChunkServer
8

9.
数据结构
 分布式Hash表
 随机读，不支持范围查询；
 Hash划分均匀；
 两种Hash：取模Hash与一致性Hash
 实例：Tair，Memcache，Dynamo，Cassandra
 分布式B+ Tree
 随机读和顺序扫描，支持范围查询；
 顺序划分不均匀，需要叶子节点分裂合幵
 实例：Bigtable & HBase，Google Megastore
 Oceanbase数据结构
 增量数据：单机B+树
 基准数据：分布式B+树
 新的基准数据 = 老的基准数据 + 增量数据
9

10.
可扩展性 & 可靠性
 可扩展性
 基准数据服务器ChunkServer
 机器动态上下线
 增量数据服务器UpdateServer
 内存+SSD服务，多网卡，万兆网卡
 备提供读服务
 可靠性
 基准数据服务器ChunkServer
 数据存储多份，一般为3份
 增量数据服务器UpdateServer
 Commit log + RAID 1磁盘
 实时本地热备(主+备) + 准实时异地热备
 定位服务器RootServer
 实时本地热备(主+备) + 准实时异地热备 10

11.
事务&一致性
 数据库事务
 单机写事务 +分布式读事务
 支持跨表事务
 一致性选择
 弱一致性
 最终一致性
 强一致性
 本地实时同步，异地准实时同步
11

12.
负载平衡 & 读写分离
 自动负载均衡
 RootServer总体协调
 负载均衡因素：内存，磁盘等资源占用，读写负载等；
 数据迁移：迁移过程不影响对外服务
 读写分离
 ChunkServer只读，简化设计幵提高读性能
 UpdateServer采用copy-on-write数据结构，写不影响读
 Oceanbase系统读和写基本不干扰
12

13.
其它特性
 其它特性
 在线修改schema
 没有随机写，SSD友好
 内置数据压缩，减少机器数量和网络数据流量
 在线(不停机)系统版本升级
13

14.
写节点是否成瓶颈?
 CPU，内存，网络，磁盘…
 内存容量
 新增的记录：1千万条/天，1KB/条10GB/天
 记录的修改：1亿条/天，100B/条10GB/天
 网络：100,000QPS，100B/条10MB/s
 磁盘
 Commit log (bin log)：Group commit
 改进方案
 SSD
 多网卡、万兆网卡
 …
14

15.
收藏夹的挑战
 收藏夹挑战
 需求：查找一个用户的所有收藏的所有商品详情
 收藏信息表保存收藏信息条目，40亿+
 收藏商品表保存收藏的商品详细信息，4亿+
 执行两张表的暴力Join？一个用户可以收藏数千商品
 冗余商品详细信息到收藏表？一件商品可被数十万用户收藏
15

16.
收藏夹解决方案
 解决方案
 收藏夹数据 = 基准数据 + 增量数据
 基准数据：收藏信息表冗余存储商品详情信息
 增量数据：收藏信息表和商品详情表分别存放到UpdateServer内
存中
 操作步骤：
1. 顺序读取基准数据中用户的收藏信息及商品详情；
2. 将增量数据中的用户收藏信息更新到读取结果中；
3. 将增量数据中的用户收藏的商品信息更新到读取结果中；
16

17.
收藏夹性能
 收藏夹性能
– 数据膨胀：冗余收藏item信息到收藏info表：~1.6TB(压缩
前)/800GB(压缩后)
– 平均响应时间<50ms
– Mysql 16 * 2减少为Oceanbase 12 + 2
17

18.
Oceanbase性能
 Oceanbase性能
 4 ChunkServer, 2 * E5520 @2.27HZ, 10 * 300GB SAS, 16GB
 21亿条记录, 压缩后160GB * 3, 10k块, 随机读, cache基本不命中
140.0
6000
30
120.0
5000
25
100.0
4000
20
80.0
3000
15
60.0 响应时间
QPS
2000
10
40.0 CS负载
1000
5
20.0
00
0.0
10
10
10 50 150 300 1000
50 150 300 1000
300 1000
CS load高：全异步模型
响应时间长：同步读 -> 预读
18/26

19.
UpdateServer性能
 UpdateServer性能
 2 * E5520 @ 2.27HZ, 24G, 千兆网卡
Size(byte) 20 100 1024 2048
QPS 78000 76000 70000 55000
Context Switch 26W 25W 21W 13W
 待优化点
 优化网络框架内存分配：优化后 QPS > 10W
 减少任务队列导致的上下文切换：优化后 QPS > 20W
 结论：UPS不是性能瓶颈
19

20.
经验教训
 高性能服务器
 数据拷贝：Direct IO，权衡接口模块化与性能
 内存分配：内存池，线程缓存
 锁：线程缓存，减少Cache锁冲突，copy-on-write数据结构
 上下文切换：替换基于任务队列的网络模型
 多UpdateServer?
 不求大而全，但求明晰的技术发展路线图
 取决于业务需求
20

21.
Oceanbase展望
 支持OLAP应用
 列式存储
 Blob支持
 MapReduce
 TPC-E
 代码开源
 …
21

22.
• weibo.com: 淘宝日照
• 个人博客：http://nosqlnotes.net
22