Ocean base --千亿级海量数据库-lamper_日照

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

2.
Agenda存储需求与现有方案

3.
Oceanbase技术方案

4.
收藏夹应用案例

5.
系统展望2

6.
在线存储需求数据库在线存储需求

7.
数据规模：百TB级，百台机器

8.
OLTP：几十万QPS，几万TPS

9.
OLAP：支持千万级记录实时计算

10.
支持事务

11.
强一致性 (vs. 弱一致性、最终一致性)

12.
可用性：5个9

13.
运维简单性：不再拆库，自动扩容3

14.
现有存储方案对照4HBaseBigtable数据规模Megastore万亿记录(十PB)OceanBase千亿记录(百TB)DynamoCassandra十亿记录(TB)RDBMS千万记录(百GB)事务与数据一致性最终一致单行事务跨行跨表事务NoSQL系统

15.
数据容量大、可扩展性好、容错能力强

16.
没有跨行跨表事务、数据一致性弱OceanBase始于2010年5月

17.
海量数据存储特点的进一步分析

18.
数据量大但修改量较小，一千亿 * 1%*100B = 100G

19.
区分最新修改的增量数据和以前的基准数据？

20.
OceanBase = RDBMS+ 云存储

21.
增量数据(增删改操作)：单机之内存+SSD

22.
基准数据：静态B+树，多机

23.
数据读取：基准数据+增量数据

24.
数据写入：增量数据

25.
事务：集中化写事务+分布式读事务5

26.
OceanBase系统架构6RootServer/ UpdateServer(主)RootServer/ UpdateServer(备)JavaClientChunkServerChunkServerChunkServerChunkServer主控服务器RootServer：主+备，数据定位/全局Schema/机器管理…

27.
增量数据服务器UpdateServer：主+备，实时修改(内存+SSD)

28.
基准数据服务器ChunkServer：多台，B+树叶子节点(磁盘或SSD)

29.
增量数据定期合并到基准数据中，从而分散到多台ChunkServer数据结构分布式Hash表

30.
随机读，不支持范围查询；

31.
Hash划分均匀；

32.
两种Hash：取模Hash与一致性Hash

33.
实例：Tair，Memcache，Dynamo，Cassandra

34.
分布式B+ Tree

35.
随机读和顺序扫描，支持范围查询；

36.
顺序划分不均匀，需要叶子节点分裂合并

37.
实例：Bigtable & HBase，GoogleMegastore

38.
Oceanbase数据结构

39.
增量数据：单机B+树

40.
基准数据：分布式B+树

41.
新的基准数据 = 老的基准数据 + 增量数据7

42.
可扩展性 & 可靠性可扩展性

43.
基准数据服务器ChunkServer

44.
机器动态上下线

45.
增量数据服务器UpdateServer

46.
内存+SSD服务，多网卡，万兆网卡

47.
备提供读服务

48.
可靠性

49.
基准数据服务器ChunkServer

50.
数据存储多份，一般为3份

51.
增量数据服务器UpdateServer

52.
Commit log +RAID 1磁盘

53.
实时本地热备(主+备) + 准实时异地热备

54.
定位服务器RootServer

55.
实时本地热备(主+备) + 准实时异地热备8

56.
事务&一致性数据库事务

57.
单机写事务 +分布式读事务

58.
支持跨表事务

59.
一致性选择

60.
弱一致性

61.
最终一致性

62.
强一致性

63.
本地实时同步，异地准实时同步9

64.
负载平衡 & 读写分离自动负载均衡

65.
RootServer总体协调

66.
负载均衡因素：内存，磁盘等资源占用，读写负载等；

67.
数据迁移：迁移过程不影响对外服务

68.
读写分离

69.
ChunkServer只读，简化设计并提高读性能

70.
UpdateServer采用copy-on-write数据结构，写不影响读

71.
Oceanbase系统读和写基本不干扰10

72.
其它特性其它特性

73.
在线修改schema

74.
没有随机写，SSD友好

75.
内置数据压缩，减少机器数量和网络数据流量

76.
在线(不停机)系统版本升级11

77.
写节点是否成瓶颈?CPU，内存，网络，磁盘…

78.
内存容量

79.
新增的记录：1千万条/天，1KB/条10GB/天

80.
记录的修改：1亿条/天，100B/条10GB/天

81.
网络：100,000QPS，100B/条10MB/s

82.
磁盘

83.
Commit log (bin log)：Group commit

84.
改进方案

85.
SSD

86.
多网卡、万兆网卡

87.
…12

88.
收藏夹的挑战收藏夹挑战

89.
需求：查找一个用户的所有收藏的所有商品详情

90.
收藏信息表保存收藏信息条目，40亿+

91.
收藏商品表保存收藏的商品详细信息，4亿+

92.
执行两张表的暴力Join？一个用户可以收藏数千商品

93.
冗余商品详细信息到收藏表？一件商品可被数十万用户收藏13

94.
收藏夹解决方案解决方案

95.
收藏夹数据 = 基准数据+ 增量数据

96.
基准数据：收藏信息表冗余存储商品详情信息

97.
增量数据：收藏信息表和商品详情表分别存放到UpdateServer内存中

98.
操作步骤：顺序读取基准数据中用户的收藏信息及商品详情；将增量数据中的用户收藏信息更新到读取结果中；将增量数据中的用户收藏的商品信息更新到读取结果中；14

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

100.
Oceanbase性能Oceanbase性能

101.
4 ChunkServer, 2 * E5520 @2.27HZ, 10 * 300GB SAS, 16GB

102.
21亿条记录, 压缩后160GB *3, 10k块, 随机读, cache基本不命中16/26响应时间长：同步读 -> 预读CS load高：全异步模型

103.
UpdateServer性能UpdateServer性能

104.
2 * E5520@ 2.27HZ, 24G, 千兆网卡

105.
待优化点

106.
优化网络框架内存分配：优化后 QPS >10W

107.
减少任务队列导致的上下文切换：优化后 QPS >20W

108.
结论：UPS不是性能瓶颈17

109.
经验教训高性能服务器

110.
数据拷贝：Direct IO，权衡接口模块化与性能

111.
内存分配：内存池，线程缓存

112.
锁：线程缓存，减少Cache锁冲突，copy-on-write数据结构

113.
上下文切换：替换基于任务队列的网络模型

114.
多UpdateServer?

115.
不求大而全，但求明晰的技术发展路线图

116.
取决于业务需求18

117.
Oceanbase展望支持OLAP应用

118.
列式存储

119.
Blob支持

120.
MapReduce

121.
TPC-E

122.
代码开源

123.
…19

124.
个人博客：http://nosqlnotes.net20谢谢

Ocean base --千亿级海量数据库-lamper_日照

More Related Content

What's hot

Viewers also liked

Similar to Ocean base --千亿级海量数据库-lamper_日照

Ocean base --千亿级海量数据库-lamper_日照