TiDB数据库设计理念与实践

1、TiDB数据库设计理念与实践技术创新，变革未来初 心心目中理想的数据库无需分库分表不用关心容量规划任意时候都能扩展，弹性伸缩部分机器损坏或者数据中心故障仍然能够提供服务已有系统迁移成本低能有更多时间喝咖啡，读书，写代码行动分布式事务算法证明 TLA+ (/pingcap/tla-plus)MySQL 协议兼容降低迁移成本水平扩展不再担心任意时刻计算和存储的弹性伸缩高可用睡个好觉Cloud native能运行在所有的云上彻底模块化，存储层，计算层，调度分离全景图（一千米外）Storage layer(tikv)SQL layer(tidb-server)SQL layer(tidb-server

2、)SQL layer(tidb-server) SQL layer(tidb-server)Storage layer(tikv)Storage layer(tikv)Storage layer(tikv) Storage layer(tikv)MySQLprotocol.scheduler全景图（近在咫尺）SQL 层无状态客户端连接任意 tidb-serverMySQL 协议支持SQLASTLogical PlanOptimized Logical PlanCost ModelSelected Physical PlanTiKVTiKVTiKVtidb-serverStatisticsTiK

3、VTiKVTiKVTiKV ClusterOLTP 到 HTAP 的演进越来越多的用户需要实时的 OLAPReal-time Warehousing当数据都在一个系统里的时候这是最自然的需求存储层 - TiKVTiKV 作为 TiDB 的底层分布式存储提供诸多特性分布式事务使用 Raft 协议做强一致的复制数据被拆分成多个 RegionRegion 可以分裂，合并，并在机器之 间来根据负载流动原生支持 Coprocessor，加速 SQL Predicate Push DownTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKVTiKV NodesC

4、lientDataflow存储层 - TiKVRegion 5Region 4Region 1Region 1Region 3Region 2Region 3Region 3Region 5TiKV node 1TiKV node 2TiKV node 3Store 1Store 2Store 3Region 5Region 1Region 2TiKV node 4Store 4RPCClient (Key Value APIs or Coprocessor Call)RPCRPCRPCPD 1PD 2PD 3Placement DriverRaft GroupRegion 4Region 4

5、Region 2一些实战经验大中台型业务多源数据实时汇总MySQL Sharding 的完美替代方案跨数据中心高可用部署异地多活和分库分表说再见MySQL MasterMySQL MasterMySQL MasterMySQL MasterMySQL MasterSyncerSyncerSyncerSyncerSynceAs Slave Clusterr大中台- Realtime unified data platform通往实时数据仓库- Spark connector异地多活- Geo replicationR1RackRackR2DC - 1DC - 2R1RackRackR2DC -

6、3R1RackRackR2R1RackRackR2DC - Seattle 1DC - Seattle 2R1RackRackR2DC - Santa ClaraR1RackRackR2After schedulingAll in TiDB- 转转公司的 TiDB 实践实施效果：TiDB 整体响应延时非常稳定，不受业务流量高 峰影响TiDB/TiKV通过线性扩容无缝提升吞吐量微信小红点、世界杯促销承担 5 倍容量增长案例文章：TiDB 分布式数据库在转转的应用实践文章链接：/R1MAXEq以前：MySQL + MongoDB大数据量性能瓶颈业务侵入 - 被迫 shading业务多维度成本、复杂

7、度叠加增加运维成本故障切换时间长 & 高可用方案解决方案：All in TiDB已经上线 11 套 OLTP 系统，1 套 OLAP 系统，包括核心的IM、交易、用户、商品等待上线 3 套，最终完成 90% 系统上线几十T 数据量、千亿级表、万级 TPS美团的 TiDB 实践案例美团数据库历史状态：MySQL + NoSQL数千服务器 + 万亿级请求数/天自研了 NoSQL 、 MySQL Proxy拥有多个业内顶级存储开发、数据库内核开发小组美团的 TiDB 实践案例美团下一代的数据库选型考量未来新美大业务几十倍的数据量增长目标，需要更强大的技术支持，数据库是关键基础组件之一所以对新一代分布

8、式关系型数据库需求量远大于传统的 MySQL + NoSQL新美大的最终选择：TiDB美团的 TiDB 实践案例线上使用情况：上线 10 套系统分布在如下 6 个事业群及平台：配送事业部出行事业部闪付事业部酒旅事业部美团平台基础研发平台OLTP 为主美团关于 TiDB 实践的一些经验开启 Region Merge 选项系统会自动将多个小 Region 合并成一个，降低路由信息维护的开销打开 dynamic-level-bytes加快删除数据后的空间回收速度更多细节参考美团的同学写的系列分享文章美团的 TiDB 实践案例深度参与开发，运维和推广专门 DBA 小组来进行 TiDB 试点、推广专门基

9、础研发小组来进行 TiDB 开发合作，涵盖 SQL 层，存储层即将发布更多源码级别的参与，改进经验系列文章HTAP 实例 - 易果生鲜的实践实施效果：T+1 数仓升级为实时数仓（T+0）。TiDB 天然的满足了数据量线性扩展的问题。同时还 大大的节省了运维成本。案例文章：TiDB / TiSpark 在易果集团实时数仓中的创新实践文章链接：/RTYVhzH业务现状：SQL Server 当数据量到达一定的阶段，性能出现拐 点，弹性扩展很难实现。HDFS + Hive + Spark + Presto + Kylin 方案在数据 量增大的情况下，ETL 越来越慢，很难满足更复杂 的 OLAP 需

10、求，但与此同时，业务对实时或者准实 时的需求越来越强烈。实施方案：使用 Flume、syncer 数据实时同步到 TiDB。使用 TiSpark 替换 Hadoop 进行实时数仓业务。某国有商业银行的 TiDB 多活银行核心实例项目背景：核心支付交易系统物理规划IDC1、IDC2各配置两个机柜，均用于部署生产主集群，IDC3一个机柜用于部署生产主集群，另一个机柜用 于部署灾备从集群。每个IDC配置两台万兆交换机（以主备模式部署），主 集群各台机器内部通信、从集群各台机器内部通信、 主从集群之间都是使用万兆网络。全局DNS下挂载三个IDC的负载均衡，各IDC种负载 均衡挂载各自中心内部的TiDB

11、服务器以上信息均来自行方 对外发布的技术文章进化将 Value 从 LSM tree 中分离出来减少写放大内存能缓存更多索引解决数据库一行比较大的问题（比如一行 4k或者更大）进化Serverless基于 K8S存储和计算资源云化已经支持 GKE(Google Kubernetes Engine) 和 AWS EKS(Amazon Elastic Container Service for Kubernetes根据负载自动/透明扩展（next step）云上自动创建 TiDB 集群教程已经上线进化冷热分离存储降低存储和计算成本简化数据管理进化行列混合引擎更好的计算性能更彻底的 HTAP更好的隔离更智能的优化器TiDB 大家可能不知道的那些事Infoworld 2018 best of open source software awardTiDB 大家可能不知道的那些事CNCF database landscapeTiDB 大家可能不知道的那些事TiKV: CNCF Sandbox Projec