TiDB

本文为我司 Engineering VP 申砾在 TiDB DevCon 2019 上的演讲实录。在 上篇 中，申砾老师重点回顾了 TiDB 2.1 的特性，并分享了我们对「如何做好一个数据库」的看法。 本篇将继续介绍 TiDB 3.0 Beta 在稳定性、易用性、功能性上的提升，以及接下来在 Storage Layer 和 SQL Layer 的规划，enjoy~ TiDB 3.0 Beta 2018 年年底我们开了一次用户吐槽大会，当时我们请了三个 TiDB 的重度用户，都是在生产环境有 10 套以上 TiDB 集群的用户。那次大会规则是大家不能讲 TiDB 的优点，只能讲缺点；研发同学要直面问题，不能辩解，直接提解决方案；当然我们也保护用户的安全（开个玩笑 :D），让他们放心的来吐槽。刚刚的社区实践分享也有点像吐槽大会第二季，我们也希望用户来提问题，分享他们在使用过程遇到什么坑， 因为只有直面这些问题，才有可能改进 。所以我们在 TiDB 3.0 Beta 中有了很多改进，当然还有一些会在后续版本中去改进。 1. Stability at Scale TiDB 3.0 版本第一个目标就是「更稳定」，特别是在大规模集群、高负载的情况下保持稳定。稳定性压倒一切，如果你不稳定，用户担惊受怕，业务时断时续，后面的功能都是没有用的。所以我们希望「先把事情做对，再做快」。 1.1

作者：肖亮亮 Table Partition 什么是 Table Partition Table Partition 是指根据一定规则，将数据库中的一张表分解成多个更小的容易管理的部分。从逻辑上看只有一张表，但是底层却是由多个物理分区组成。相信对有关系型数据库使用背景的用户来说可能并不陌生。 TiDB 正在支持分区表这一特性。在 TiDB 中分区表是一个独立的逻辑表，但是底层由多个物理子表组成。物理子表其实就是普通的表，数据按照一定的规则划分到不同的物理子表类内。程序读写的时候操作的还是逻辑表名字，TiDB 服务器自动去操作分区的数据。 分区表有什么好处？ 优化器可以使用分区信息做分区裁剪。在语句中包含分区条件时，可以只扫描一个或多个分区表来提高查询效率。 方便地进行数据生命周期管理。通过创建、删除分区、将过期的数据进行 高效的归档，比使用 Delete 语句删除数据更加优雅，打散写入热点，将一个表的写入分散到多个物理表，使得负载分散开，对于存在 Sequence 类型数据的表来说（比如 Auto Increament ID 或者是 create time 这类的索引）可以显著地提升写入吞吐。 分区表的限制 TiDB 默认一个表最多只能有 1024 个分区 ，默认是不区分表名大小写的。 Range, List, Hash 分区要求分区键必须是 INT 类型，或者通过表达式返回

作者：徐怀宇 聚合算法执行原理 在 SQL 中，聚合操作对一组值执行计算，并返回单个值。TiDB 实现了 2 种聚合算法：Hash Aggregation 和 Stream Aggregation。 我们首先以 AVG 函数为例（案例参考 Stack Overflow ），简述这两种算法的执行原理。 假设表 t 如下： 列 a 列 b 1 9 1 -8 2 -7 2 6 1 5 2 4 SQL: select avg(b) from t group by a , 要求将表 t 的数据按照 a 的值分组，对每一组的 b 值计算平均值。不管 Hash 还是 Stream 聚合，在 AVG 函数的计算过程中，我们都需要维护 2 个中间结果变量 sum 和 count 。Hash 和 Stream 聚合算法的执行原理如下。 Hash Aggregate 的执行原理 在 Hash Aggregate 的计算过程中，我们需要维护一个 Hash 表，Hash 表的键为聚合计算的 Group-By 列，值为聚合函数的中间结果 sum 和 count 。在本例中，键为 列 a 的值，值为 sum(b) 和 count(b) 。 计算过程中，只需要根据每行输入数据计算出键，在 Hash 表中找到对应值进行更新即可。对本例的执行过程模拟如下。 输入数据 a b Hash 表 [key] (sum,

作者：黄东旭 2018 年对于 TiDB 和 PingCAP 来说是一个由少年向成年的转换的一年，如果用一个关键字来概括就是「蜕变」 。在这一年很欣喜的看到 TiDB 和 TiKV 在越来越多的用户使用在了越来越广泛的场景中，作为一个刚刚 3 岁多的开源项目，没有背后强大的社区的话，是没有办法取得这样的进展的。 同时在技术上，2018 年我觉得也交出了一份令人满意的答卷，TiDB 的几个主要项目今年一共合并了 4380 个提交，这几天在整理 2018 年的 Change Log 时候，对比了一下年初的版本，这 4380 个 Commits 背后代表了什么，这里简单写一个文章总结一下。 回想起来，TiDB 是最早定位为 HTAP 的通用分布式数据库之一，如果熟悉我们的老朋友一定知道，我们最早时候一直都是定位 NewSQL，当然现在也是。但是 NewSQL 这个词有个问题，到底 New 在哪，解决了哪些问题，很难一目了然，其实一开始我们就想解决一个 MySQL 分库分表的问题，但是后来慢慢随着我们的用户越来越多，使用的场景也越来越清晰，很多用户的场景已经开始超出了一个「更大的 MySQL 」的使用范围，于是我们从实验室和学术界找到了我们觉得更加清晰的定义：HTAP，希望能构建一个融合 OLTP 和 OLAP 通用型分布式数据库。但是要达成这个目标非常复杂

2019 年 5 月 10 日，TiDB 发布 3.0.0-rc.1 版，对应的 TiDB-Ansible 版本为 3.0.0-rc.1。相比 3.0.0-beta.1 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。 TiDB SQL 优化器 利用列之间的顺序相关性提升代价估算准确度，并提供启发式参数 tidb_opt_correlation_exp_factor 用于控制在相关性无法被直接用于估算的场景下对索引扫描的偏好程度。 当过滤条件中包含相关列时，在抽取复合索引的访问条件时尽可能多地匹配索引的前缀列。 用动态规划决定连接的执行顺序，当参与连接的表数量不多于 tidb_opt_join_reorder_threshold 时启用。 在构造 Index Join 的的内表中，以复合索引作为访问条件时，尽可能多地匹配索引的前缀列。 提升对单列索引上值为 NULL 的行数估算准确度。 在逻辑优化阶段消除聚合函数时特殊处理 GROUP_CONCAT ，防止产生错误的执行结果。 当过滤条件为常量时，正确地将它下推到连接算子的子节点上。 在逻辑优化阶段列剪裁时特殊处理一些函数，例如 RAND() ，防止产生和 MySQL 不兼容的执行结果。 支持 FAST ANALYZE ，通过 tidb_enable_fast_analyze 变量控制

2019 年 03 月 26 日，TiDB 发布 3.0.0 Beta.1 版，对应的 TiDB-Ansible 版本为 3.0.0 Beta。相比 3.0.0 Beta 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。 TiDB SQL 优化器 支持使用 Sort Merge Join 计算笛卡尔积 支持 Skyline Pruning，用一些规则来防止执行计划过于依赖统计信息 支持 Window Functions NTILE LEAD 和 LAG PERCENT_RANK NTH_VALUE CUME_DIST FIRST_VALUE 和 LAST_VALUE RANK 和 DENSE_RANK RANGE FRAMED ROW FRAMED ROW NUMBER 增加了一类统计信息，表示列和 handle 列之间顺序的相关性 SQL 执行引擎 增加内建函数 JSON_QUOTE JSON_ARRAY_APPEND JSON_MERGE_PRESERVE BENCHMARK COALESCE NAME_CONST 根据查询上下文优化 Chunk 大小，降低 SQL 执行时间和集群的资源消耗 权限管理 支持 SET ROLE 和 CURRENT_ROLE 支持 DROP ROLE 支持 CREATE ROLE Server 新增 /debug

作者：段兵 2019 年 5 月 10 日，TiDB 3.0.0-rc.1 版本正式推出，该版本对系统稳定性，性能，安全性，易用性等做了较多的改进，接下来逐一介绍。 提升系统稳定性 众所周知，数据库的查询计划的稳定性至关重要，此版本采用多种优化手段促进查询计划的稳定性得到进一步提升，如下： 新增 Fast Analyze 功能，使 TiDB 收集统计信息的速度有了数量级的提升，对集群资源的消耗和生产业务的影响比普通 Analyze 方式更小。 新增 Incremental Analyze 功能，对于值单调增的索引能够更加方便和快速地更新其统计信息。 在 CM-Sketch 中新增 TopN 的统计信息，缓解因为 CM-Sketch 哈希冲突导致估算偏大的问题，使代价估算更加准确。 优化 Cost Model，利用和 RowID 列之间的相关性更加精准的估算谓词的选择率，使得索引选择更加稳定和准确。 提升系统性能 TableScan,IndexScan,Limit 算子，进一步提升 SQL 执行性能。 TiKV 采用 Iterator Key Bound Option 存储结构减少内存分配及拷贝，RocksDB 的 Column Families 共享 block cache 提升 cache命中率等手段大幅提升性能。 TiDB Lightning encode SQL 性能提升

TiDB 是 Cloud Native 的数据库，对于 TiDB 来说，如何用 Cloud 的思想和技术让 TiDB 在云上跳舞，是 Cloud 团队研究的重要课题，本期我司商业产品副总裁刘寅老师将为大家介绍 Cloud 团队，Enjoy~ TiDB 与 Cloud 通过前面的招聘职位解读系列文章，相信大家对开发 TiDB 的挑战有了更深入理解。水平弹性伸缩是 TiDB 最酷的特性之一，不同于传统的单机数据库，TiDB 管理的往往是成百上千的分布式存储节点、计算节点以及监控、日志相关组件，这对于 TiDB 的使用来说是非常大的挑战。 因此，我们在开发 TiDB 之初，就将其定义为 Cloud Native 的数据库。我们意识到需要用 Cloud 的思想和技术，让 TiDB 用起来更加简单，开发者和用户才能够轻松 “玩转” TiDB。 Cloud Engineering Team 在 PingCAP 我们有一支专门的团队在做和 Cloud 相关的事情。这里的 Cloud 是一个比较泛泛的概念，它既包括公有云，也包含私有部署，凡是关于“如何以集群化和集中式来管理大规模的 TiDB 实例”的问题都是这个团队需要关心的事情。看到这里小伙伴们可能已经想到了容器和 Kubernetes。是的，容器是在 Cloud 上部署和管理的最佳实践，Cloud Team 的一个主要职责就是把 TiDB

提到「开源项目 TiDB」人们总是习惯性反应：它在 GitHub 上 Star 数已经超过 17000，并拥有 260+ 位全球各地的 Contributors 。但数据总归是冷冰冰的，不能生动的展现 TiDB 社区的魅力。所以今天推送一篇 TiDB contributor 杜川同学加入 TiDB 社区前后的「心路历程」，他从亲历者的角度告诉你—— PingCAPer 够 nice 么？ 积极参与 TiDB 社区对自己的能力提升有何帮助？ 如何在 TiDB 星球上找到最适合自己的落点？（ 或者在大树上找到自己最擅长的“小树杈”hhhhhh） 以及…利用好碎片时间，你也可以一年给 TiDB 提 70 个 PR！ ** 作者：杜川，TiDB contributor** 最近这一年多断断续续一直在往 TiDB 中提交一些修改，前两天看了一些 GitHub 提交记录，发现竟然已经累计了 70 来个 PR 了。考虑到最近这一年基本处于疯狂加班的节奏，另外忙里偷闲还基本上刷完了之前列的十几本书的读书清单，我觉得这也算一个不大不小的成就吧，值得 mark 一下。 话说回来，虽然我 17 年年中才开始给 TiDB 提交 PR，其实在之前一年多以前，大概在 2016 年 4 月份左右, 就听说过 TiDB 这个项目了。当时我的主要工作也是车一个 SQL 执行引擎

作者：Kenny Chan 简介 TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集，自 2.1.0 版本起随 TiDB 发布，速度可达到传统执行 SQL 导入方式的至少 3 倍、大约每小时 100 GB，适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。 设计 TiDB 从 2017 年开始提供全量导入工具 Loader ，它以多线程操作、错误重试、断点续传以及修改一些 TiDB 专属配置来提升数据导入速度。 然而，当我们全新初始化一个 TiDB 集群时，Loader 这种逐条 INSERT 指令在线上执行的方式从根本上是无法尽用性能的。原因在于 SQL 层的操作有太强的保证了。在整个导入过程中，TiDB 需要： 保证 ACID 特性，需要执行完整的事务流程。 保证各个 TiKV 服务器数据量平衡及有足够的副本，在数据增长的时候需要不断的分裂、调度 Regions。 这些动作确保 TiDB 整段导入的期间是稳定的，但在导入完毕前我们根本不会对外提供服务，这些保证就变成多此一举了。此外，多线程的线上导入也代表资料是乱序插入的，新的数据范围会与旧的重叠。TiKV 要求储存的数据是有序的，大量的乱序写入会令 TiKV 要不断地移动原有的数据（这称为 Compaction），这也会拖慢写入过程。 TiKV 是使用