深度解密POLARDB新版本： MySQL 8.0

1 .封仲淹 阿里云智能资深技术专家 

2 .深度解密POLARDB新版本： MySQL 8.0 封仲淹 

3 . Agenda 基本介绍 用户场景 技术解密 总结 

4 . 为什么做POLARDB MySQL DBA 的痛 使用了读写分离， 刚更新的数据， 查询不到。。 活动上线，容量评估不足，压力陡增， 数据库来不及升级 容量即将超过3T, 没时间做分库分表改造 1T数据备份或恢复, 要十几小时 容量超过500G, 查询慢的如蜗牛 主从复制经常中断，1236 1042错误 添加一个字段，备库延迟3小时 

5 . POLARDB 100% 兼容MySQL 云原生数据库 物理机 物理机 物理机 虚拟机 容器 虚拟机 容器 虚拟机 容器 主 读 读 数据库A 数据库B 数据库C 数据库B 数据库D 数据库B 共享存储 共享存储 共享存储 

6 . POLARDB 架构 Host2 内核解决 Host1 •秒级备份 data route POLARDB POLARDB POLARDB •跨 az 访问 control route libpfs libpfs libpfs 管控需求 •全链路监控性能 volume 1 Volume 2 volume 1 chunk1 chunk2 chunk1 chunk2 chunk1 chunk2 metadata •容量 按需支付 PolarCtrl PolarSwitch PolarSwitch 弹性 •性能， 水平/垂直任意升降级 ChunkServer ChunkServer ChunkServer ChunkServer chunk chunk chunk chunk 拥抱新硬 •RDMA •NVME/Optane 件 ParallelRaft •FPGA Key Components: 1. libpfs 2. PolarSwitch 3. ChunksServer 4. PolarCtrl 

7 .应用场景1: 海量数据 

8 .* 商家数量以每年70%速度增长，峰值时刻经常出现数据库卡顿，交易等 待时间一度上升到5秒。 * 业务发展速度快，平均3个月打满一个MySQL数据库，费时费力。 * 原计划保留40天数据，每天1TB日志， 现在5天即满30T。 * 5秒一个话单，5分钟一个分表。 * 运行超过88个国家级资源库，56个国家级备选资源库，400余个省会级 资源库，覆盖高职教育所有专业大类，课程超6000余门，习题120余万 道，媒体资源近250余万条。 * 单库已超10TB。 

9 .应用场景2: 多库聚合 

10 . 场景：海量电子合同的归档及查询 前端服务器 SLB 法大大有4个数据中心分别存储不同客户的数 据，随着客户的数量逐渐增加，数据的爆发式 数据中心1 数据中心2 数据中心3 数据中心4 增长，传统的MySQL数据库无法满足存储存储 电子合同应用服务集群 海量的历史数据的需求。 历史数据查询 实在在线数据查询 目前，POLARDB已经存储法大大超过6亿的 读写分离 负载均衡 电子合同数据，这些数据可以安全的存储在 ETL .... 数据中心3 ETL POLARDB，作为Elasticsearch的底层数据源提供 ETL ETL POLARDB POLARDB POLARDB 给官网展示，解决了主业务库容量的瓶颈。 数据中心1 主节点 只读节点 只读节点 数据中心2 数据中心4 MySQL数据库服务群 Elasticsearch 

11 . 技术解密 应用场景1: 海量数据 应用场景2: 多库聚合 

12 . 海量存储 Host1 Host2 data route POLARDB POLARDB POLARDB control route libpfs libpfs libpfs • Distribute File System volume 1 Volume 2 volume 1 chunk1 chunk2 chunk1 chunk2 chunk1 chunk2 metadata PolarCtrl PolarSwitch PolarSwitch ChunkServer ChunkServer ChunkServer ChunkServer chunk chunk chunk chunk ParallelRaft Key Components: 1. libpfs 2. PolarSwitch 3. ChunksServer 4. PolarCtrl 

13 . 并行查询（POLARDB for MySQL 8.0 新特性） SELECT count(*) FROM production.product; SQL Client Thread 1: Scan, Count 1 active thread 63 idle threads 官方MySQL单线程处理查询 

14 . 并行查询（POLARDB for MySQL 8.0 新特性） Thread 1: Scan, SELECT count(*) FROM production.product; Count Thread 2: Scan, Count Thread 3: Scan, With 64 parallel Count threads, each thread does < 2% of SQL Thread 4: Scan, the work. Client Sum Count Thread 5: Scan, Count Thread 6: Scan, Count Thread 7: Scan, Count ... Thread 64: Scan, Count 

15 . 并行查询（POLARDB for MySQL 8.0 新特性） Partitioning InnoDB partitions the B-tree 6 partitions Workers see only one partition (at a time) 11 17 25 5 8 14 20 22 28 31 1 2 34 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Part. 1 Part. 2 Part. 3 Part. 4 Part. 5 Part. 6 

16 . 并行查询（POLARDB for MySQL 8.0 新特性） Speedup 35x • 32 并发时： 30x • TPCH 有9条查询可以被加速 25x • TPCH 有7条查询加速超过16倍 20x 15x 10x 5x 0x Q1 Q3 Q5 Q6 Q9 Q10 Q12 Q14 Q19 

17 . Performance： POLARDB 8.0 vs POLARDB 5.6 oltp_write_only oltp_read_only 500000 500000 450000 450000 400000 400000 350000 350000 300000 300000 QPS QPS 250000 250000 200000 200000 150000 150000 100000 100000 50000 50000 0 0 64 128 256 512 1024 64 128 256 512 1024 polardb 80 272916.31 392207.37 444574.15 416712.46 373066.99 polardb 80 404722.81 463549.03 468034.49 446471.5 421132.28 polardb 56 167003.11 230667.03 281244.57 235252.19 60614.36 polardb 56 64749.74 93562.4 143981.73 153386.22 143118.21 oltp_insert oltp_delete 300000 500000 450000 250000 400000 350000 200000 300000 QPS QPS 150000 250000 200000 100000 150000 100000 50000 50000 0 0 64 128 256 512 1024 64 128 256 512 1024 polardb 80 115511.25 152968.45 208319.7 260770.28 246810.55 polardb 80 174883.34 292096.14 419572.28 455342.13 404179.68 polardb 56 64749.74 93562.4 143981.73 153386.22 143118.21 polardb 56 69110.03 98452.29 137440.7 146847.35 58551.59 In the above figures, the values on the horizontal axis (such as 64, 128, .., 1024) respectively means the number threads that sysbench using in each test. 

18 . Performance： POLARDB 8.0 vs POLARDB 5.6 oltp_update_index oltp_update_non_index 200000 180000 180000 160000 160000 140000 140000 120000 120000 100000 QPS QPS 100000 80000 80000 60000 60000 40000 40000 20000 20000 0 0 64 128 256 512 1024 64 128 256 512 1024 polardb 80 88564.7 131969.35 159271.41 181438.98 181534.69 polardb 80 100229.1 153119.25 167970.78 160635.19 143726.21 polardb 56 10006.78 11796.06 86095.63 104572.46 47759.28 polardb 56 54562.25 86042.32 128443.57 126234.59 57032.61 oltp_read_write 450000 400000 350000 300000 250000 QPS 200000 150000 100000 50000 0 64 128 256 512 1024 polardb 80 336534.43 411366.66 419961.61 388498.82 327836.39 polardb 56 269858.63 363391.41 387903.73 337285.56 251862.99 In the above figures, the values on the horizontal axis (such as 64, 128, .., 1024) respectively means the number threads that sysbench using in each test. 

19 .应用场景3: 高吞吐/读写分离 

20 .场景：百胜ISHOP在线零售商城 百胜iSHOP在线商城是以移动互联网时代消费者驱动业务为 核心，充分满足企业在不同触点场景下实现互动、体验、便 捷交易的统一及业务成长的中高端电子商务销售平台。 百胜目前服务30多万家实体POS门店与2万多家网上商店，随 着业务量增长与业务波动传统的关系型数据库难以满足业务 增长需求 

21 .应用场景4: 弹性升降级 

22 . 场景：在线直播中小学课程辅导 猿辅导的在线课堂同时有数十万学生使用。不同的 课堂采用名师在线出题，学生答题后，答题结果即 时同步和反馈到讲师端应用，根据学生答题的情况, 及时调整教学方案。 OSS 对象存储 学生在线考试，日常10万人在线，峰值激增至20 万，近1/3学生无法正常进入考试，答题延时从日常 Web应用 Web应用 Web应用 Web应用 的1秒以内增长到平均5秒，体验剧降。 （云服务器） （云服务器） （云服务器） （云服务器） 读写分离 负载均衡 读写分离 负载均衡 日常支撑30万学生同时在线根据业务无压力，提 RDMA 前1小时准备，业务能力可临时提升至100万 POLARDB POLARDB POLARDB POLARDB 主节点 只读节点 主节点 只读节点 

23 . 技术解密 应用场景3: 高吞吐/读写分离 应用场景4: 弹性升降级 

24 . Application Read/Write Split Load Balance Proxy Cluster • 快速地弹性伸缩 High Availability Security • 会话读一致性 • 自带读写分离的高可用服务 Master Replica Replica Replica Shared Storage 

25 .应用场景5: 高可用 – 秒级备份 

26 . 场景：玩具展厅线上商务平台 澄宏互动科技有限公司提供先进的玩具展厅信息平台， OSS 连接全世界的玩具制造商，贸易公司，供应链以及批发厂 对象存储 商，提供玩具产业链的信息整合和大数据分析服务。展厅线 上系统提供近百万个玩具样本的多维属性信息，并且以每个 月增加几百万条的速度增长。该展厅承载了中国近80%的玩具 产业信息。为超过3万家的玩具厂商和2万家左右的配件厂商 Web 提供服务，是整合玩具原料，生产，销售，展示，信息搜索 Web 服务器 服务器 VPC 连接 服务等玩具信息生态产业的一体化商务平台。 读写分离 RDMA负载均衡 防止了人为误操作导致的数据删除、数据污染等灾难，需要 对线上业务无影响的秒级别快速备份能力，同时提供数据按 时间点恢复能力 POLARDB POLARDB POLARDB 主节点 只读节点 只读节点 

27 .应用场景6: 高可用 -- 异地容灾 

28 . 基于北斗卫星系统提供动态亚米级、厘米级和静态毫米级的定 位能力，是IoT时代重要的基础设施之一，利用超过2000个地 基增强站及自主研发定位算法，通过互联网技术为遍布全国的 用户提供精准定位及延展服务. 北京故障的情况下，上海region可在30秒内接管业务。 并发定位作业峰值10万左右，每年20%增长，定位时延需 控制在1秒以内 北京 上海 

29 . 技术解密 应用场景5: 高可用 – 秒级备份 应用场景6: 高可用 – 异地容灾