TiKV

作者：周昱行 在整个 SQL 执行过程中，需要经过 Parser，Optimizer，Executor，DistSQL 这几个主要的步骤，最终数据的读写是通过 tikv-client 与 TiKV 集群通讯来完成的。 为了完成数据读写的任务，tikv-client 需要解决以下几个具体问题： 如何定位到某一个 key 或 key range 所在的 TiKV 地址？ 如何建立和维护和 tikv-server 之间的连接？ 如何发送 RPC 请求？ 如何处理各种错误？ 如何实现分布式读取多个 TiKV 节点的数据？ 如何实现 2PC 事务？ 我们接下来就对以上几个问题逐一解答，其中 5、6 会在下篇中介绍。 如何定位 key 所在的 tikv-server 我们需要回顾一下之前 《三篇文章了解 TiDB 技术内幕——说存储》 这篇文章中介绍过的一个重要的概念：Region。 TiDB 的数据分布是以 Region 为单位的，一个 Region 包含了一个范围内的数据，通常是 96MB 的大小，Region 的 meta 信息包含了 StartKey 和 EndKey 这两个属性。当某个 key >= StartKey && key < EndKey 的时候，我们就知道了这个 key 所在的 Region，然后我们就可以通过查找该 Region 所在的 TiKV 地址

本文为我司 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

作者：黄东旭 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 团队职位解读文章 ，当天就有很多简历砸来，我们深深感受到了小伙伴们的热情～ 趁热打铁，今天我司首席架构师 唐刘 老师将带大家了解一下传说中「面试通过率最低、难度最高」的研发团队—— TiKV 团队 。 Team 简介 我们 Team 主要负责 TiKV 的研发工作，下图是我们产品的架构图，大家可以看到，无论是 TiDB 还是 TiSpark，都是从 TiKV 存取数据的，所以我们一定要保证 TiKV 的稳定和高效。 在我们官网招聘页面，TiKV 研发工程师的岗位职责就两个： 负责分布式数据库 TiKV 相关的设计，开发。 负责构建分布式压力测试框架，稳定性测试框架。 是不是特别简单？说实话，我们也想好好写清楚，但无奈 TiKV 这边要做的事情实在是太多，所以这里我会详细介绍一下。 TiKV 研发工程师职位信息： https://pingcap.com/recruit-cn/engineering/tikv-engineer/ TiKV 简介 TiKV 是一个支持事务的、数据强一致的分布式 Key-Value 数据库。也许有人会说，造一个 Key-Value 数据库有啥难的，我不这么认为，因为造一个工业级、通用的、有超高性能的 Key-Value，真的是一件很难的事情。而且这个 Key-Value 数据库上面还加了很多限定词来修饰，要支持这些特性就更难了

作者：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 是使用

作者：赵一霖 在 上篇文章 中，我们主要介绍了 Pump Server 的上线过程、gRPC API 实现、以及下线过程和相关辅助机制，其中反复提到了 Pump Storage 这个实体。本文就将介绍 Pump Storage 的实现，其主要代码在 pump/storage 文件夹中。 Pump Storage 由 Pump Server 调用，主要负责 binlog 的持久化存储，同时兼顾排序、配对等功能，下面我们由 Storage 接口开始了解 Pump Storage 的实现。 Storage interface Storage 接口 定义了 Pump Storage 对外暴露的操作，其中比较重要的是 WriteBinlog 、 GC 和 PullCommitBinlog 函数，我们将在下文具体介绍。Storage 的接口定义如下： type Storage interface { // WriteBinlog 写入 binlog 数据到 Storage WriteBinlog(binlog *pb.Binlog) error // GC 清理 tso 小于指定 ts 的 binlog GC(ts int64) // GetGCTS 返回最近一次触发 GC 指定的 ts GetGCTS() int64 // AllMatched 返回是否所有的 P-binlog 都和 C

作者：周昱行 上篇文章 中，我们介绍了数据读写过程中 tikv-client 需要解决的几个具体问题，本文将继续介绍 tikv-client 里的两个主要的模块——负责处理分布式计算的 copIterator 和执行二阶段提交的 twoPhaseCommitter。 copIterator copIterator 是什么 在介绍 copIterator 的概念之前，我们需要简单回顾一下前面 TiDB 源码阅读系列文章（六） 中讲过的 distsql 和 coprocessor 的概念以及它们和 SQL 语句的关系。 tikv-server 通过 coprocessor 接口，支持部分 SQL 层的计算能力，大部分只涉及单表数据的常用的算子都可以下推到 tikv-server 上计算，计算下推以后，从存储引擎读取的数据虽然是一样的多，但是通过网络返回的数据会少很多，可以大幅节省序列化和网络传输的开销。 distsql 是位于 SQL 层和 coprocessor 之间的一层抽象，它把下层的 coprocessor 请求封装起来对上层提供一个简单的 Select 方法。执行一个单表的计算任务。最上层的 SQL 语句可能会包含 JOIN ， SUBQUERY 等复杂算子，涉及很多的表，而 distsql 只涉及到单个表的数据。一个 distsql 请求会涉及到多个 region