腾讯基础架构部数据库研发负责人程彬 - 腾讯云数据库CDB技术演进之路

2020-02-27 1297浏览

  • 1.腾讯云数据库CDB技术演进之路
  • 2.目录 • 云数据库概览 • CDB之存储篇 • CDB之复制篇 • CDB之引擎篇
  • 3.云数据库概览-什么是云数据库 云计算 NIST关于云计算服务的基本特征定义 ü 随需应变自助服务 ü 随时随地用任何网络设备访问 ü 多人共享资源池 ü 快速重新部署灵活度 ü 可被监控与量测的服务 p 满足云计算特征的数据库服务 p 数据库内核+云化功能
  • 4.云数据库概览-鹅厂的云数据库 p SQL p NoSQL CDB
  • 5.云数据库概览-CDB内核技术栈 接入集群 ü 路由 ü 安全 ü HA 实例集群 TXSQL LogBus复制通道 ü 数据库引擎 ü 多副本复制 TXSQL TXSQL 存储集群 ü 数据存储
  • 6.CDB之存储篇-三次存储革命 SAS-Raid 阶段1 SSDCluster1.0 阶段2 SSD 阶段3 SSDCluster2.0 阶段4 p 根据存储介质特性，进行数据库存储技术设计 p 数据库存储的本质：面向块的存储
  • 7.CDB之存储篇-第一次革命 p SAS  Raid存储的主要矛盾 ü 性能问题：随机IO性能不高 ü 扩展性问题：单机最大存储容量受限 ü 成本问题：价格贝佐斯定律带给成本的挑战 p SSD  Raid存储可行性 ü 选择SATA S  SD：2011年PCI-E S  SD刚刚兴起 ü 性能问题：随机IO性能有较大提升 ü 扩展性问题：依旧存在 ü 成本问题：单位存储成本更高 ü SSD使用的问题：写放大、写性能下降 p 解决问题的思路 ü 基于SSD的存储系统有吗？ 分布式KV ü 分布式KV解决了性能、扩展性、SSD使用问题 ü 分布式KV和数据库存储的联系：block ü 块block的数据模型(Disk, L  BA, V  alue)<->(Key, V  alue) 文件读写 文件系统 磁盘块读写 SAS阵列 基于SAS阵列的数据库存储
  • 8.CDB之存储篇-第一次革命(Cont.1) p SSD  Cluster1.0存储 ü 虚拟块设备+IO网络化à块读写转化为KV操作 ü 适配SSD特性的KV存储系统 ü MySQL层优化：千兆网络瓶颈 & 去  double w  rite ü 文件系统&块设备调优 ü 成本问题：按需分配、动态伸缩、 p 运营中的故事 ü 存储集群的蝴蝶效应 文件读写 文件系统 磁盘块读写 虚拟块设备 网络KV读写 SSD-KV 基于SSD  Cluster1.0的数据库存储
  • 9.CDB之存储篇-第二次革命 p SSD  Cluster1.0的主要矛盾 ü 开发商的变化：IO密集型核心应用上云 ü 存储介质的变化：PCI-E S  SD量大价低 ü 性能不够，性价比没优势 p PCI-E  SSD  Cluster存储可行性 ü IO性能：相比本地，网络和分布式带来额外开销 ü 扩展性：单机最大本地存储6T ü SSD使用的问题：SSD F  TL的进一步优化 ü 成本问题：相比本地，优势有，但已不是主要矛盾 ü 运维成本：相比本地，更高 p 解决问题的思路 ü 选择本地PCI-E  SSD ü 选择新的技术制高点：数据库引擎本身的性能和稳定性 文件读写 文件系统 磁盘块读写 基于PCI-E  SSD的数据库存储
  • 10.CDB之存储篇-第三次革命 p PCI-E  SSD的主要矛盾 ü 开发商的变化：金融、政企等数据库上云 ü DB要求：兼容性、RTO、RPO、扩展性四个都不能少 ü 扩展性问题：容量无法和SAN\NAS\专有存储相比 ü 中间件sharding解决了扩展性问题，但兼容性有问题 p 解决问题的思路 ü 主要目标：100TB以下，SQL完全兼容的传统行业DB服务 ü SDP：Shared  Disk  Parallel ü 数据库节点和存储分离，数据库节点有主从之分 ü 尽量减少IO次数：主数据库节点才能写存储集群，从节点不会写
  • 11.CDB之复制篇-三种复制模式 异步复制 阶段1 半同步复制 阶段2 强一致复制 阶段3 p 复制结合机房部署，灵活选择，达到最有效的容灾效果
  • 12.CDB之复制篇-半同步的一些问题 p MySQL半同步的主要问题 ü 无法做到强一致：自动降级、灵活的多zone部署下的一致性要求 ü 半同步下性能下降多 MySQL  Native  Semi  Sync  Replication 
  • 13.CDB之复制篇-性能优化 p 性能关键因子 ü 单个事务耗时：用户层面的响应时间，每个事务耗时多少ms ü 系统整体吞吐：服务层面的处理能力，一台机器每秒能处理事务数(TPS) p 单个事务耗时 ü Ttotal=Tsql+Tengine+Treplicate ü Tsql和Tengine在同步复制下不是关键瓶颈 ü Treplicate=Tbinlog网络传输+Tslave落地binlog，Tbinlog网络传输取决于RTT值 ü 测试数据： ü 全cache下MySQL异步单事务耗时3.37ms； ü 半同步单事务耗时8.33ms，测试环境RTT值2.6ms，Tslave落地binlog为1.9ms ü 测试机器顺序512B的write+fsync延时0.13ms，Tslave落地binlog优化空间大 p 系统整体吞吐 ü 吞吐=并发数/单个事务耗时 ü 并发数取决于各种资源的利用率，如master的事务线程、master的binlog发送/响应 线程、slave的binlog接收线程等利用率情况
  • 14.CDB之复制篇-性能优化(Cont.1) p MySQL  slave的IO线程接收binlog耗时原因 ü 锁冲突：IO/SQL线程间的锁冲突，如元数据文件锁 ü 小IO消耗：IO线程离散小磁盘IO消耗过多的IOPS ü 串行化：IO线程接收和落盘操作串行 p 构建独立于MySQL的快速复制通道logbus ü 基于semisync协议，模拟slave向master建立主从关系，同步binlog ü 避免原生相关耗时瓶颈 ü 外置logbus，减少对MySQL的侵入，方便各种分支兼容 数据库版本 MySQL5.7 MySQL5.7 MySQL5.7 同步类型 TPS 单事务耗时(ms) 同步RTT 性能基准对比 异步 半同步 logbus 33193 3.82 15395 8.32 22169 5.92 2.60 2.60 2.60 100% 46.30% 66.79%
  • 15.CDB之复制篇-性能优化(Cont.2) p 优化MySQL  5.6的binlog发送、响应 ü binlog同步阻塞传输模型：master b  inlog dump线程发送某个事务 binlog后，等待slave回包后，再发送下一个事务binlog。理论上最大 QPS=1000/RTT(ms)。一般情况同城跨园区之间RTT为3ms左右，QPS峰值 约330 ü 方案： master  binlog发送和接收异步化，dump线程负责发送，ack线程 负责处理回包，通知事务线程继续提交 master SND  Tx1 ACK  Tx1 slave master slave Tx3 Tx2 。。。 Tx1 SND  Tx2 ACK  Tx2 ACK1 ACK2 ACK3 。。。 。。。
  • 16.CDB之引擎篇-TXSQL 面向运维优化 面向bug优化 面向性能优化 深度定制 阶段1 阶段2 阶段3 阶段4 p 自研技术：20+ p 社区红利：30+
  • 17.CDB之引擎篇-TXSQL特性概览
  • 18.