Ocean base 千亿级海量数据库-日照
22
LAMP人 主题分享交流会 www.LAMPER.cn QQ群：3330312 http://weibo.com/lampercn
-
Upload
shaoning-pan -
Category
Documents
-
view
1.825 -
download
4
description
Ocean base 千亿级海量数据库-日照
Transcript of Ocean base 千亿级海量数据库-日照
LAMP人 主题分享交流会
www.LAMPER.cn
QQ群：3330312
http://weibo.com/lampercn
LAMP人 主题分享交流会
www.LAMPER.cn
QQ群：3330312
http://weibo.com/lampercn
Agenda
存储需求与现有方案
Oceanbase技术方案
收藏夹应用案例
系统展望
4
在线存储需求
数据库在线存储需求 数据规模：百TB级，百台机器
OLTP：几十万QPS，几万TPS
OLAP：支持千万级记录实时计算
支持事务
强一致性 (vs. 弱一致性、最终一致性)
可用性：5个9
运维简单性：不再拆库，自动扩容
5
现有存储方案对照
NoSQL系统
数据容量大、可扩展性好、容错能力强
没有跨行跨表事务、数据一致性弱 6
数据规模
事务与数据一致性
万亿记录(十PB)
千亿记录(百TB)
千万记录(百GB)
十亿记录(TB)
最终一致 单行事务 跨行跨表事务
RDBMS
Cassandra
HBase
Megastore
OceanBase
Dynamo
Bigtable
OceanBase
始于2010年5月
海量数据存储特点的进一步分析 数据量大但修改量较小，一千亿 * 1%* 100B = 100G
区分最新修改的增量数据和以前的基准数据？
OceanBase = RDBMS + 云存储 增量数据(增删改操作)：单机之内存+SSD
基准数据：静态B+树，多机
数据读取 ：基准数据+增量数据
数据写入 ：增量数据
事务：集中化写事务+分布式读事务
7
OceanBase系统架构
主控服务器RootServer：主+备，数据定位/全局Schema/机器管理…
增量数据服务器UpdateServer：主+备，实时修改(内存+SSD)
基准数据服务器ChunkServer：多台，B+树叶子节点 (磁盘或SSD)
增量数据定期合幵到基准数据中，从而分散到多台ChunkServer8
JavaClient
ChunkServer ChunkServer ChunkServer ChunkServer
RootServer/
UpdateServer
(主)
RootServer/
UpdateServer
(备)
数据结构
分布式Hash表 随机读，不支持范围查询；
Hash划分均匀；
两种Hash：取模Hash与一致性Hash
实例：Tair，Memcache，Dynamo，Cassandra
分布式B+ Tree
随机读和顺序扫描，支持范围查询；
顺序划分不均匀，需要叶子节点分裂合幵
实例：Bigtable & HBase，Google Megastore
Oceanbase数据结构 增量数据：单机B+树
基准数据：分布式B+树
新的基准数据 = 老的基准数据 + 增量数据
9
可扩展性 & 可靠性
可扩展性 基准数据服务器ChunkServer
机器动态上下线
增量数据服务器UpdateServer
内存+SSD服务，多网卡，万兆网卡
备提供读服务
可靠性 基准数据服务器ChunkServer
数据存储多份，一般为3份
增量数据服务器UpdateServer
Commit log + RAID 1磁盘
实时本地热备(主+备) + 准实时异地热备
定位服务器RootServer
实时本地热备(主+备) + 准实时异地热备 10
事务&一致性
数据库事务 单机写事务 +分布式读事务
支持跨表事务
一致性选择 弱一致性
最终一致性
强一致性
本地实时同步，异地准实时同步
11
负载平衡 & 读写分离
自动负载均衡 RootServer总体协调
负载均衡因素：内存，磁盘等资源占用，读写负载等；
数据迁移：迁移过程不影响对外服务
读写分离 ChunkServer只读，简化设计幵提高读性能
UpdateServer采用copy-on-write数据结构，写不影响读
Oceanbase系统读和写基本不干扰
12
其它特性
其它特性 在线修改schema
没有随机写，SSD友好
内置数据压缩，减少机器数量和网络数据流量
在线(不停机)系统版本升级
13
写节点是否成瓶颈?
CPU，内存，网络，磁盘…
内存容量 新增的记录：1千万条/天，1KB/条10GB/天
记录的修改：1亿条/天，100B/条10GB/天
网络：100,000QPS，100B/条10MB/s
磁盘 Commit log (bin log)：Group commit
改进方案 SSD
多网卡、万兆网卡
…
14
收藏夹的挑战
收藏夹挑战 需求：查找一个用户的所有收藏的所有商品详情
收藏信息表保存收藏信息条目，40亿+
收藏商品表保存收藏的商品详细信息，4亿+
执行两张表的暴力Join？一个用户可以收藏数千商品
冗余商品详细信息到收藏表？一件商品可被数十万用户收藏
15
收藏夹解决方案
解决方案 收藏夹数据 = 基准数据 + 增量数据
基准数据：收藏信息表冗余存储商品详情信息
增量数据：收藏信息表和商品详情表分别存放到UpdateServer内存中
操作步骤：
1. 顺序读取基准数据中用户的收藏信息及商品详情；
2. 将增量数据中的用户收藏信息更新到读取结果中；
3. 将增量数据中的用户收藏的商品信息更新到读取结果中；
16
收藏夹性能
收藏夹性能– 数据膨胀：冗余收藏item信息到收藏info表：~1.6TB(压缩
前)/800GB(压缩后)
– 平均响应时间<50ms
– Mysql 16 * 2减少为Oceanbase 12 + 2
17
Oceanbase性能
Oceanbase性能 4 ChunkServer, 2 * E5520 @2.27HZ, 10 * 300GB SAS, 16GB
21亿条记录, 压缩后160GB * 3, 10k块, 随机读, cache基本不命中
18/26
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
10 50 150 300 1000
响应时间
0
1000
2000
3000
4000
5000
6000
10 50 150 300 1000
QPS
0
5
10
15
20
25
30
10 50 150 300 1000
CS负载
响应时间长：同步读 -> 预读CS load高：全异步模型
UpdateServer性能
UpdateServer性能 2 * E5520 @ 2.27HZ, 24G, 千兆网卡
待优化点
优化网络框架内存分配：优化后 QPS > 10W
减少任务队列导致的上下文切换：优化后 QPS > 20W
结论：UPS不是性能瓶颈
19
Size(byte) 20 100 1024 2048
QPS 78000 76000 70000 55000
Context Switch 26W 25W 21W 13W
经验教训
高性能服务器 数据拷贝：Direct IO，权衡接口模块化与性能
内存分配：内存池，线程缓存
锁：线程缓存，减少Cache锁冲突，copy-on-write数据结构
上下文切换：替换基于任务队列的网络模型
多UpdateServer?
不求大而全，但求明晰的技术发展路线图
取决于业务需求
20
Oceanbase展望
支持OLAP应用
列式存储
Blob支持
MapReduce
TPC-E
代码开源
…
21
