ocean base --千亿级海量数据库-2011数据库大会
TRANSCRIPT
海量数据的挑战2010 部分运营数据
注册会员: 3.7 亿,来访人群峰值 6000 万 日 PV :超过 20 亿 在线商品数: 8 亿 每分钟销售商品: 4.8 万 交易额:单日超 10 亿,光棍节 19.5 亿
淘宝商品库、评价库、交易订单库、用户库、店铺库…今后几年信息量还将增长几倍到几十倍分库分表也不一定总是奏效
3数据来源: http://www.alibuybuy.com/posts/52702.html
互联网数据库互联网时代的数据库
支持 80% 以上互联网在线应用数据规模:百 TB 级,百台机器OLTP :几十万 QPS ,几万 TPSOLAP :支持千万级记录实时计算定义支持的 SQL 子集标准支持 MapReduce 等时髦计算模型TPC-E更多,。。。
4
现有存储方案对照
NoSQL 系统 数据容量大、可扩展性好、容错能力强 没有跨行跨表事务、数据一致性弱 5
数据规模
事务与数据一致性
万亿记录( 十 PB)
千亿记录( 百 TB)
千万记录( 百 GB)
十亿记录(TB)
最终一致 单行事务 跨行跨表事务
RDBMS
Cassandra
HBaseMegastore
OceanBase
Dynamo
Bigtable
OceanBase
始于 2010 年 5 月海量数据存储特点的进一步分析
数据量大但修改量较小,一亿次更新 * 100B = 10G 区分最新修改的数据和老数据?
OceanBase = RDBMS + 云存储 动态数据 ( 增删改 ) :单机之内存 +SSD 静态数据:静态 B+ 树,多机 数据 = 静态数据 + 动态数据 事务:集中化写事务+分布式读事务
6
OceanBase 系统架构
主控服务器 RootServer :主 + 备,数据定位 / 全局 Schema/ 机器管理…
动态数据服务器 UpdateServer :主 + 备,实时修改 ( 内存 +SSD) 静态数据服务器 ChunkServer :多台,静态数据存储 ( 磁盘或
SSD) 动态数据不断地被合并到静态 ChunkServer 中实现分布式存储
7
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+ 树新的静态数据 = 老的静态数据 + 动态数据
8
可扩展性 & 可靠性可扩展性
静态数据服务器 ChunkServer机器动态上下线
动态数据服务器 UpdateServer内存 +SSD 服务,多网卡,万兆网卡备提供读服务
可靠性静态数据服务器 ChunkServer
数据存储多份,一般为 3 份动态数据服务器 UpdateServer
Commit log + RAID 1 磁盘实时本地热备 ( 主 + 备 ) + 准实时异地热备
定位服务器 RootServer实时本地热备 ( 主 + 备 ) + 准实时异地热备
9
负载平衡 & 读写分离自动负载均衡
RootServer 总体协调负载均衡因素:内存,磁盘等资源占用,读写负载等;数据迁移:迁移过程不影响对外服务
读写分离 ChunkServer 只读,简化设计并提高读性能 UpdateServer采用 copy-on-write 数据结构,写不影响读 Oceanbase 系统读和写基本不干扰
11
写节点是否成瓶颈 ?
CPU ,内存,网络,磁盘…内存容量
新增的记录: 1 千万条 /天, 1KB/条 10GB/天 记录的修改: 1 亿条 /天, 100B/条 10GB/天
网络: 100,000QPS , 100B/条 10MB/s磁盘
Commit log (bin log) : Group commit改进方案
SSD 多网卡、万兆网卡 …
13
收藏夹的挑战收藏夹挑战
需求:查找一个用户的所有收藏的所有商品详情 收藏信息表保存收藏信息条目, 40 亿 + 收藏商品表保存收藏的商品详细信息, 4 亿 + 执行两张表的暴力 Join ?一个用户可以收藏数千商品 冗余商品详细信息到收藏表?一件商品可被数十万用户收藏
14
15/26
收藏夹解决方案解决方案
收藏夹数据 = 静态数据 + 动态数据 静态数据:收藏信息表冗余存储商品详情信息 动态数据:收藏信息表和商品详情表分别存放到 UpdateServer
内存中 操作步骤:
1. 顺序读取静态数据中用户的收藏信息及商品详情;2. 将动态数据中的用户收藏信息更新到读取结果中;3. 将动态数据中的用户收藏的商品信息更新到读取结果中;
16/26
收藏夹性能收藏夹性能
– 数据膨胀:冗余收藏 item 信息到收藏 info 表: ~1.6TB(压缩前 )/800GB(压缩后 )
– 平均响应时间<50ms– Mysql 16 * 2减少为 Oceanbase 12 + 2
Oceanbase 性能Oceanbase 性能
4 ChunkServer, 2 * E5520 @2.27HZ, 10 * 300GB SAS, 16GB
21 亿条记录 , 压缩后 160GB * 3, 10k块 , 随机读 , cache基本不命中
17/26
10 50 150 300 10000.0
20.0 40.0 60.0 80.0
100.0 120.0 140.0
响应时间
10 50 150 300 10000
1000
2000
3000
4000
5000
6000
QPS
10 50 150 300 10000
5
10
15
20
25
30
CS 负载
响应时间长:同步读 -> 预读CS load高:全异步模型
18/26
UpdateServer 性能UpdateServer 性能
2 * E5520 @ 2.27HZ, 24G, 千兆网卡
待优化点优化网络框架内存分配:优化后 QPS > 10W减少任务队列导致的上下文切换:优化后 QPS > 20W
结论: UPS 不是性能瓶颈
Size(byte) 20 100 1024 2048
QPS 78000 76000 70000 55000
Context Switch 26W 25W 21W 13W
经验教训高性能服务器
数据拷贝: Direct IO ,权衡接口模块化与性能 内存分配:内存池,线程缓存 锁:线程缓存,减少 Cache锁冲突, copy-on-write 数据结构 上下文切换:替换基于任务队列的网络模型
19