TiDB

作者介绍 ：孙晓光，知乎技术平台团队负责人，负责建设知乎在线和离线的基础设施平台，为业务开发提供统一的基础设施。曾多年从事私有云相关产品开发工作，关注云原生技术，TiKV 项目 Committer。 关注 TiDB 的朋友们可能发现继 Follower Read 在 TiKV 端的 PR 合并后，TiDB 端相关的 PR 也于近期完成了到主干的合并工作。如果后期的稳定性测试一切正常，相关功能应该会随 TiDB 3.1 发布。Follower Read 功能本身从代码量上看并不大，但这个功能的意义尤其是对互联网类型业务来说是非常大的。 前段时间 PingCAP CTO 黄东旭已经写了 一篇文章 ，从原理角度对 Follower Read 做了非常透彻的介绍和分析。今天我想从非技术的角度介绍 Follower Read 功能的落地过程，并从 Contributor 的视角跟大家聊一聊个人参与 TiDB 开发过程中的体验和感受。最后站在知乎技术平台团队的角度，聊一下我们未来在积极参与开源项目，共同建设社区的愿望和决心。 Follower Read 背后的故事 Follower Read 的实现思路在 PingCAP 工程师大脑里应该已经存在很久了，但出于各种原因这个特性的优先级一直不够高，并没有能排到开发计划中。年中的时候我们开始尝试在知乎更广泛的业务中引入 TiDB

作者：赵一霖 背景知识 SQL 语句发送到 TiDB 后首先会经过 parser，从文本 parse 成为 AST（抽象语法树），AST 节点与 SQL 文本结构是一一对应的，我们通过遍历整个 AST 树就可以拼接出一个与 AST 语义相同的 SQL 文本。 对 parser 不熟悉的小伙伴们可以看 TiDB 源码阅读系列文章（五）TiDB SQL Parser 的实现 。 为了控制 SQL 文本的输出格式，并且为方便未来新功能的加入（例如在 SQL 文本中用 “*” 替代密码），我们引入了 RestoreFlags 并封装了 RestoreCtx 结构（ 相关源码 ）： // `RestoreFlags` 中的互斥组: // [RestoreStringSingleQuotes, RestoreStringDoubleQuotes] // [RestoreKeyWordUppercase, RestoreKeyWordLowercase] // [RestoreNameUppercase, RestoreNameLowercase] // [RestoreNameDoubleQuotes, RestoreNameBackQuotes] // 靠前的 flag 拥有更高的优先级。 const ( RestoreStringSingleQuotes RestoreFlags = 1

作者：Yuanjia Zhang 在 上篇文章 中，我们介绍了 TiDB 如何实现表达式的向量化优化，以及社区同学如何参与这项工程。两周过去了，我们收到了很多来自社区小伙伴们的建议和反馈，今天在这里和大家分享一下活动进展和这些建议及反馈。 活动进展 先来看看这两周的活动进展吧。截至 9 月 30 日中午，所有 Issue 中需要向量化的函数签名总共有 517 个，目前已完成 89 个，占总体的 17%。其中绝大多数的函数签名向量化都是由社区开发者们完成的，感谢大家的贡献！ 各类型函数签名的完成度如下，我们通过这几个 Issue 来追踪向量化的工作进展，欢迎大家去里面挑选感兴趣的，还未被其他人认领的函数签名去实现： Date/Time builtin functions (7/65) Decimal builtin functions (7/31) Int builtin functions (22/187) JSON builtin functions (1/27) Real builtin functions (28/49) String builtin functions (19/113) Duration builtin functions (5/45) FAQ Q1：前期开发过程中，PR 很容易和主干代码冲突，如何解决？ A1：在前期的开发过程中，我们发现大家的 PR

2019 年 1 月 19 日，TiDB 发布 3.0 Beta 版，对应 master branch 的 TiDB-Ansible。相比 2.1 版本，该版本对系统稳定性、优化器、统计信息以及执行引擎做了很多改进。 TiDB 新特性 支持 View 支持 Window Function 支持 Range Partition 支持 Hash Partition SQL 优化器 重新支持聚合消除的优化规则 优化 NOT EXISTS 子查询，将其转化为 Anti Semi Join 添加 tidb_enable_cascades_planner 变量以支持新的 Cascades 优化器。目前 Cascades 优化器尚未实现完全，默认关闭 支持在事务中使用 Index Join 优化 Outer Join 上的常量传播，使得对 Join 结果里和 Outer 表相关的过滤条件能够下推过 Outer Join 到 Outer 表上，减少 Outer Join 的无用计算量，提升执行性能 调整投影消除的优化规则到聚合消除之后，消除掉冗余的 Project 算子 优化 IFNULL 函数，当输入参数具有非 NULL 的属性的时候，消除该函数 支持对 _tidb_rowid 构造查询的 Range，避免全表扫，减轻集群压力 优化 IN 子查询为先聚合后做 Inner Join 并，添加变量

TiDB 社区有一个信念是：我们从不给自己设限，突破&提升才是一直追求的常态。在 去年举办的 TiDB 黑客马拉松 上，诞生了很多兼具想象力和实用性的 TiDB 生态工具，我们当然也并不满足于此—— 10 月 26 - 27 日，TiDB Hackathon 2019 重磅回归！本届主题较去年更加广泛： IMPROVE · 跃 界 本届比赛将弱化地域限制，北京、上海、广州三地联动 奖金依然丰厚，但好点子无价 大咖导师巡场带教，10 分钟零距离交流可能胜过埋头苦思 1 个月 啤酒 Pizza 不眠夜，期待各路大神集结，享受代码世界中的极致自由 冲撞 跨越 爆发，让 TiDB 来一次简单粗暴、突破常规的「跃界」吧 选题方向 参赛选手可以为 TiDB 性能、易用性、稳定性、功能等各方面做出提升，当然也可以围绕 TiDB 生态做一些周边工具提升效率，比如： Key Visualizer for TiKV 可视化的 KV 的诊断工具，做到对集群的热点，访问模式一目了然。 基于历史的查询优化 让 TiDB 的 SQL 优化器能通过稳态的查询历史生成稳定的执行计划，防止执行计划跳变。 Follower Read 与 MVCC 的结合 让 TiDB 的多副本能够承担读流量， 提升整体的吞吐。 TiDB Playground 类似 Go Playground (play.golang.org)

作者：MingCong Han 在《 十分钟成为 Contributor 系列 | 为 Cascades Planner 添加优化规则 》中，我们简单介绍了 Cascades 的相关背景知识，本文将为大家深入介绍 TiDB 新的优化器——Cascades Planner 的框架及原理。 TiDB 当前优化器简介 关系型数据库中查询优化器的作用是为一个 SQL 在合理的开销内产生一个合适的查询计划， TiDB 源码阅读系列文章（六）Select 语句概览 中介绍过 TiDB 当前优化器的基本组成，TiDB 当前的优化器将优化过程主要分为逻辑优化（Logical Optimize）和物理优化（Physical Optimize）两个阶段。逻辑优化是将一棵逻辑算子树（LogicalPlan Tree）进行逻辑等价的变化，最后的结果是一棵更优的逻辑算子树；而物理优化则是将一棵逻辑算子树转换成一棵物理算子树（PhysicalPlan Tree）。这棵物理算子树就是我们说的物理执行计划，将交由 TiDB 执行引擎去完成后续的 SQL 执行过程。 逻辑优化 TiDB 中，一个 SQL 在进入到逻辑优化阶段之前，它的 AST（抽象语法树）已经转换成了对应的逻辑算子树，因此逻辑优化就是将一个逻辑算子树进行逻辑上等价变换的过程。逻辑优化是基于规则的优化（Rule-Based Optimization

作者：杨非 本文为 DM 源码阅读系列文章的第十篇，之前的文章已经详细介绍过 DM 数据同步各组件的实现原理和代码解析，相信大家对 DM 的实现细节已经有了深入的了解。本篇文章将从质量保证的角度来介绍 DM 测试框架的设计和实现，探讨如何通过多维度的测试方法保证 DM 的正确性和稳定性。 测试体系 DM 完整的测试体系包括以下四个部分： 1. 单元测试 主要用于测试每个 go 模块和具体函数实现的正确性，测试用例编写和测试运行方式依照 go 单元测试的标准，测试代码跟随项目源代码一起发布。具体测试用例编写使用 pingcap/check 工具包，该工具包是在 go 原生测试工具基础上进行的扩展， 按照 suite 分组进行测试 ，提供包括更丰富的检测语法糖、并行测试、序列化测试在内的一些扩展特性。单元测试的设计出发点是白盒测试，测试用例中通过尽可能明确的测试输入得到期望的测试输出。 2. 集成测试 用于测试各个组件之间交互的正确性和完整数据同步流程的正确性，完整的 测试用例集合和测试工具在项目代码的 tests 目录 发布。集成测试首先自定义了一些 DM 基础测试工具集 ，包括启动 DM 组件，生成、导入测试数据，检测同步状态、上下游数据一致性等 bash 脚本，每个测试用例是一个完整的数据同步场景，通过脚本实现数据准备、启动 DM 集群、模拟上游数据输入、特定异常和恢复

作者：lan 本文为 DM 源码阅读系列文章的第五篇。 上篇文章 介绍了 dump 和 load 两个数据同步处理单元的设计实现，对核心 interface 实现、数据导入并发模型、数据导入暂停或中断的恢复进行了分析。 本篇文章将详细地介绍 DM 核心处理单元 Binlog replication，内容包含 binlog 读取、过滤、路由、转换，以及执行等逻辑。 文内涉及到 shard merge 相关逻辑功能，如 column mapping、shard DDL 同步处理，会在 shard merge 篇单独详细讲解，这里就不赘述了。 Binlog replication 处理流程 从上图可以大致了解到 Binlog replication 的逻辑处理流程，对应的 逻辑入口代码 。 从 relay log 或者 MySQL/MariaDB 读取 binlog events。 对 binlog events 进行处理转换（transformation），这里可以做三类操作： 操作 说明 Filter 根据 库/表同步黑白名单 对库/表进行过滤；根据 binlog event 类型过滤 。 Routing 根据 库/表 路由规则 对库/表名进行转换，用于合库合表。 Convert 将 binlog 转换为 job 对象 ，发送到 executor。 executor 对 job

作者：张学程 简介 TiDB-DM（Data Migration）是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的数据导入到 TiDB，也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。特别地，对于有多个 MySQL/MariaDB 实例的分库分表需要合并后同步到同一个 TiDB 集群的场景，DM 提供了良好的支持。如果你需要从 MySQL/MariaDB 迁移到 TiDB，或者需要将 TiDB 作为 MySQL/MariaDB 的从库，DM 将是一个非常好的选择。 架构设计 DM 是集群模式的，其主要由 DM-master、DM-worker 与 DM-ctl 三个组件组成，能够以多对多的方式将多个上游 MySQL 实例的数据同步到多个下游 TiDB 集群，其架构图如下： DM-master：管理整个 DM 集群，维护集群的拓扑信息，监控各个 DM-worker 实例的运行状态；进行数据同步任务的拆解与分发，监控数据同步任务的执行状态；在进行合库合表的增量数据同步时，协调各 DM-worker 上 DDL 的执行或跳过；提供数据同步任务管理的统一入口。 DM-worker：与上游 MySQL 实例一一对应，执行具体的全量、增量数据同步任务；将上游

作者介绍 ：刘春雷，58 集团高级 DBA，负责 MySQL 和 TiDB 的运维工作，TUG Ambassador。 58 集团业务种类繁多，目前包括的业务有 58 同城、赶集网、安居客、58 金融公司、中华英才网、驾校一点通等，数据库种类包括 MySQL、Redis、MongoDB、ES、TiDB。我们自己构建了“58 云 DB 平台”，整合了所有数据库的一体化运维。 本文将重点从运维的角度，介绍 TiDB 在 58 集团应用实践及后续计划。 一、TiDB 在 58 集团的使用概况 我们目前使用 TiDB 的服务器为 50+ 台，服务器的配置为 24 核的 CPU，128G 内存，用的是宝存的闪存卡。部署 TiKV 实例 88 个，集群共 7 套，每个业务一套集群，涉及到 TiDB 多个版本。由于是单集群多个库，目前库的数量大概是 21 个左右。磁盘目前数据量并不算大，在 10T 左右。涵盖的业务线大概目前有 7 条，包括 58 招聘、TEG、安居客、用户增长、信息安全、金融公司还有车业务，后续还会有比较多的业务推进。 二、业务需求及解决方案 <center>图 1 业务及需求</center> 业务需求目前有 4 点： 有大容量、需要长期保留的数据 目前 MySQL 都是单机存储，物理机容量有限，大约是 3T 的单机容量，由于磁盘空间瓶颈，MySQL 扩容比较麻烦。