Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,022 views

Published on

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

  • Be the first to comment

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

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

×