Your SlideShare is downloading. ×
0
OceanBase千亿级海量数据库<br />2011.5<br />日照:rizhao.ych@taobao.com<br />1<br />
Agenda<br /><ul><li>存储需求与现有方案
Oceanbase技术方案
收藏夹应用案例
系统展望</li></ul>2<br />
在线存储需求<br /><ul><li>数据库在线存储需求
数据规模:百TB级,百台机器
OLTP:几十万QPS,几万TPS
OLAP:支持千万级记录实时计算
支持事务
强一致性 (vs. 弱一致性、最终一致性)
可用性:5个9
运维简单性:不再拆库,自动扩容</li></ul>3<br />
现有存储方案对照<br />4<br />HBase<br />Bigtable<br />数据规模<br />Megastore<br />万亿记录(十PB)<br />OceanBase<br />千亿记录(百TB)<br />Dynamo...
数据容量大、可扩展性好、容错能力强
没有跨行跨表事务、数据一致性弱</li></li></ul><li>OceanBase<br /><ul><li>始于2010年5月
海量数据存储特点的进一步分析
数据量大但修改量较小,一千亿 * 1%* 100B = 100G
区分最新修改的增量数据和以前的基准数据?
OceanBase = RDBMS + 云存储
Upcoming SlideShare
Loading in...5
×

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

1,497

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,497
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
58
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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

  1. 1. OceanBase千亿级海量数据库<br />2011.5<br />日照:rizhao.ych@taobao.com<br />1<br />
  2. 2. Agenda<br /><ul><li>存储需求与现有方案
  3. 3. Oceanbase技术方案
  4. 4. 收藏夹应用案例
  5. 5. 系统展望</li></ul>2<br />
  6. 6. 在线存储需求<br /><ul><li>数据库在线存储需求
  7. 7. 数据规模:百TB级,百台机器
  8. 8. OLTP:几十万QPS,几万TPS
  9. 9. OLAP:支持千万级记录实时计算
  10. 10. 支持事务
  11. 11. 强一致性 (vs. 弱一致性、最终一致性)
  12. 12. 可用性:5个9
  13. 13. 运维简单性:不再拆库,自动扩容</li></ul>3<br />
  14. 14. 现有存储方案对照<br />4<br />HBase<br />Bigtable<br />数据规模<br />Megastore<br />万亿记录(十PB)<br />OceanBase<br />千亿记录(百TB)<br />Dynamo<br />Cassandra<br />十亿记录(TB)<br />RDBMS<br />千万记录(百GB)<br />事务与数据一致性<br />最终一致<br />单行事务<br />跨行跨表事务<br /><ul><li>NoSQL系统
  15. 15. 数据容量大、可扩展性好、容错能力强
  16. 16. 没有跨行跨表事务、数据一致性弱</li></li></ul><li>OceanBase<br /><ul><li>始于2010年5月
  17. 17. 海量数据存储特点的进一步分析
  18. 18. 数据量大但修改量较小,一千亿 * 1%* 100B = 100G
  19. 19. 区分最新修改的增量数据和以前的基准数据?
  20. 20. OceanBase = RDBMS + 云存储
  21. 21. 增量数据(增删改操作):单机之内存+SSD
  22. 22. 基准数据:静态B+树,多机
  23. 23. 数据读取 :基准数据+增量数据
  24. 24. 数据写入 :增量数据
  25. 25. 事务:集中化写事务+分布式读事务</li></ul>5<br />
  26. 26. OceanBase系统架构<br />6<br />RootServer/ UpdateServer<br />(主)<br />RootServer/ UpdateServer<br />(备)<br />JavaClient<br />ChunkServer<br />ChunkServer<br />ChunkServer<br />ChunkServer<br /><ul><li>主控服务器RootServer:主+备,数据定位/全局Schema/机器管理…
  27. 27. 增量数据服务器UpdateServer:主+备,实时修改(内存+SSD)
  28. 28. 基准数据服务器ChunkServer:多台,B+树叶子节点(磁盘或SSD)
  29. 29. 增量数据定期合并到基准数据中,从而分散到多台ChunkServer</li></li></ul><li>数据结构<br /><ul><li>分布式Hash表
  30. 30. 随机读,不支持范围查询;
  31. 31. Hash划分均匀;
  32. 32. 两种Hash:取模Hash与一致性Hash
  33. 33. 实例:Tair,Memcache,Dynamo,Cassandra
  34. 34. 分布式B+ Tree
  35. 35. 随机读和顺序扫描,支持范围查询;
  36. 36. 顺序划分不均匀,需要叶子节点分裂合并
  37. 37. 实例:Bigtable & HBase,Google Megastore
  38. 38. Oceanbase数据结构
  39. 39. 增量数据:单机B+树
  40. 40. 基准数据:分布式B+树
  41. 41. 新的基准数据 = 老的基准数据 + 增量数据</li></ul>7<br />
  42. 42. 可扩展性 & 可靠性<br /><ul><li>可扩展性
  43. 43. 基准数据服务器ChunkServer
  44. 44. 机器动态上下线
  45. 45. 增量数据服务器UpdateServer
  46. 46. 内存+SSD服务,多网卡,万兆网卡
  47. 47. 备提供读服务
  48. 48. 可靠性
  49. 49. 基准数据服务器ChunkServer
  50. 50. 数据存储多份,一般为3份
  51. 51. 增量数据服务器UpdateServer
  52. 52. Commit log + RAID 1磁盘
  53. 53. 实时本地热备(主+备) + 准实时异地热备
  54. 54. 定位服务器RootServer
  55. 55. 实时本地热备(主+备) + 准实时异地热备</li></ul>8<br />
  56. 56. 事务&一致性<br /><ul><li>数据库事务
  57. 57. 单机写事务 +分布式读事务
  58. 58. 支持跨表事务
  59. 59. 一致性选择
  60. 60. 弱一致性
  61. 61. 最终一致性
  62. 62. 强一致性
  63. 63. 本地实时同步,异地准实时同步</li></ul>9<br />
  64. 64. 负载平衡 & 读写分离<br /><ul><li>自动负载均衡
  65. 65. RootServer总体协调
  66. 66. 负载均衡因素:内存,磁盘等资源占用,读写负载等;
  67. 67. 数据迁移:迁移过程不影响对外服务
  68. 68. 读写分离
  69. 69. ChunkServer只读,简化设计并提高读性能
  70. 70. UpdateServer采用copy-on-write数据结构,写不影响读
  71. 71. Oceanbase系统读和写基本不干扰</li></ul>10<br />
  72. 72. 其它特性<br /><ul><li>其它特性
  73. 73. 在线修改schema
  74. 74. 没有随机写,SSD友好
  75. 75. 内置数据压缩,减少机器数量和网络数据流量
  76. 76. 在线(不停机)系统版本升级</li></ul>11<br />
  77. 77. 写节点是否成瓶颈?<br /><ul><li>CPU,内存,网络,磁盘…
  78. 78. 内存容量
  79. 79. 新增的记录:1千万条/天,1KB/条10GB/天
  80. 80. 记录的修改:1亿条/天,100B/条10GB/天
  81. 81. 网络:100,000QPS,100B/条10MB/s
  82. 82. 磁盘
  83. 83. Commit log (bin log):Group commit
  84. 84. 改进方案
  85. 85. SSD
  86. 86. 多网卡、万兆网卡
  87. 87. …</li></ul>12<br />
  88. 88. 收藏夹的挑战<br /><ul><li>收藏夹挑战
  89. 89. 需求:查找一个用户的所有收藏的所有商品详情
  90. 90. 收藏信息表保存收藏信息条目,40亿+
  91. 91. 收藏商品表保存收藏的商品详细信息,4亿+
  92. 92. 执行两张表的暴力Join?一个用户可以收藏数千商品
  93. 93. 冗余商品详细信息到收藏表?一件商品可被数十万用户收藏</li></ul>13<br />
  94. 94. 收藏夹解决方案<br /><ul><li>解决方案
  95. 95. 收藏夹数据 = 基准数据 + 增量数据
  96. 96. 基准数据:收藏信息表冗余存储商品详情信息
  97. 97. 增量数据:收藏信息表和商品详情表分别存放到UpdateServer内存中
  98. 98. 操作步骤:</li></ul>顺序读取基准数据中用户的收藏信息及商品详情;<br />将增量数据中的用户收藏信息更新到读取结果中;<br />将增量数据中的用户收藏的商品信息更新到读取结果中;<br />14<br />
  99. 99. 收藏夹性能<br /><ul><li>收藏夹性能</li></ul>数据膨胀:冗余收藏item信息到收藏info表:~1.6TB(压缩前)/800GB(压缩后)<br />平均响应时间<50ms<br />Mysql 16 * 2减少为Oceanbase 12 + 2<br />15<br />
  100. 100. Oceanbase性能<br /><ul><li>Oceanbase性能
  101. 101. 4 ChunkServer, 2 * E5520 @2.27HZ, 10 * 300GB SAS, 16GB
  102. 102. 21亿条记录, 压缩后160GB * 3, 10k块, 随机读, cache基本不命中</li></ul>16/26<br />响应时间长:同步读 -> 预读<br />CS load高:全异步模型<br />
  103. 103. UpdateServer性能<br /><ul><li>UpdateServer性能
  104. 104. 2 * E5520 @ 2.27HZ, 24G, 千兆网卡
  105. 105. 待优化点
  106. 106. 优化网络框架内存分配:优化后 QPS > 10W
  107. 107. 减少任务队列导致的上下文切换:优化后 QPS > 20W
  108. 108. 结论:UPS不是性能瓶颈</li></ul>17<br />
  109. 109. 经验教训<br /><ul><li>高性能服务器
  110. 110. 数据拷贝:Direct IO,权衡接口模块化与性能
  111. 111. 内存分配:内存池,线程缓存
  112. 112. 锁:线程缓存,减少Cache锁冲突,copy-on-write数据结构
  113. 113. 上下文切换:替换基于任务队列的网络模型
  114. 114. 多UpdateServer?
  115. 115. 不求大而全,但求明晰的技术发展路线图
  116. 116. 取决于业务需求</li></ul>18<br />
  117. 117. Oceanbase展望<br /><ul><li>支持OLAP应用
  118. 118. 列式存储
  119. 119. Blob支持
  120. 120. MapReduce
  121. 121. TPC-E
  122. 122. 代码开源
  123. 123. …</li></ul>19<br />
  124. 124. 个人博客:http://nosqlnotes.net<br />20<br />谢谢<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×