TiDB

作者：申砾 本文是 PingCAP 招聘职位深度解读系列的第一篇，我司 Engineering VP 申砾老师将为大家介绍 TiDB 团队（一群无法抑制内心技术骚动的人!）。 TiDB 团队工作方向 简单来说，TiDB 是一个分布式高可用且能够水平扩展的关系型数据库，这个数据库的内核包含三个组件，其中的 SQL 层组件的名字也叫做 TiDB 。这个组件负责所有和 SQL 计算相关的事情以及和客户端（业务）之间的交互，这是一个承上启下的核心模块。除了负责 TiDB 组件之外， TiDB 团队还负责开发与其他数据库之间的数据迁移和同步组件，比如 TiDB 自身的 Binlog 模块以及读取 MySQL 之类数据源 Binlog 的组件。 来 TiDB 团队你能做什么 TiDB 研发工程师职位信息: https://www.pingcap.com/recruit-cn/engineering/tidb-engineer/ 招聘职位上的「岗位职责」简单写了下面三点： 负责分布式数据库查询优化器和执行引擎相关的设计，开发，文档撰写和新人指导； 负责分布式数据库 SQL 层的设计，开发和性能优化； 参与分布式数据库底层系统存储系统的设计。 这里可以做的事情非常多，下面我会详细地介绍。 正确性 数据库最难的部分在于如何保证正确性，这个是需要具备严谨思维+想象力的工程问题

TiDB 压力测试报告 （转载自公众号DBATech） 一、测试环境 1、tidb 集群架构： 测试使用最基本的TiDB架构。即 3个tidb-server节点+ 3个tikv节点 + 3个pd节点。 2、tidb集群的部署环境(混合部署)： 192.168.xx.A 1*server +1*PD +1*tikv 192.168.xx.B 1*server +1*PD +1*tikv 192.168.xx.C 1*server +1*PD+1*tikv IDC机器环境： 0S ：CentOS7 CPU ：Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz *24 RAM ：48GB DISK ：SSD, 480GB RAID0 TiDB 重要配置参数 以下这些参数都是会对tidb造成性能影响的参数。设置尽量折中。较少对性能的影响。 tidb-server节点的设置： [log] level = "warn" [prepared-plan-cache] enabled = true log-level = "warning" [raftstore] sync-log = false tikv节点的设置： log-level = "warning" [rocksdb.defaultcf] [rocksdb.writecf] block-cache

作者：姚维 TiDB Binlog Overview 这篇文章不是讲 TiDB Binlog 组件的源码，而是讲 TiDB 在执行 DML/DDL 语句过程中，如何将 Binlog 数据 发送给 TiDB Binlog 集群的 Pump 组件。目前 TiDB 在 DML 上的 Binlog 用的类似 Row-based 的格式。具体 Binlog 具体的架构细节可以参考这篇 文章 。 这里只描述 TiDB 中的代码实现。 DML Binlog TiDB 采用 protobuf 来编码 binlog，具体的格式可以见 binlog.proto 。这里讨论 TiDB 写 Binlog 的机制，以及 Binlog 对 TiDB 写入的影响。 TiDB 会在 DML 语句提交，以及 DDL 语句完成的时候，向 pump 输出 Binlog。 Statement 执行阶段 DML 语句包括 Insert/Replace、Update、Delete，这里挑 Insert 语句来阐述，其他的语句行为都类似。首先在 Insert 语句执行完插入（未提交）之前，会把自己新增的数据记录在 binlog.TableMutation 结构体中。 // TableMutation 存储表中数据的变化 message TableMutation { // 表的 id，唯一标识一个表 optional

作者：王相 本文为 DM 源码阅读系列文章的第七篇，在 上篇文章 中我们介绍了 relay log 的实现，主要包括 relay log 目录结构定义、relay log 数据的处理流程、主从切换支持、relay log 的读取等逻辑。 本篇文章我们将会对 DM 的定制化数据同步功能进行详细的讲解。 在一般的数据同步中，上下游的数据是一一对应的，即上下游的库名、表名、列名以及每一列的值都是相同的，但是很多用户因为业务的原因希望 DM 在同步数据到 TiDB 时进行一些定制化的转化。下面我们将主要介绍数据同步定制化中的库表路由（Table routing）、黑白名单（Black & white table lists）、列值转化（Column mapping）、binlog 过滤（Binlog event filter）四个主要功能的实现。值得注意的是，由于其他一些工具（例如 TiDB Lightning 和 TiDB Binlog）也需要类似的功能，所以这四个功能都以 package 的形式维护在 tidb-tools 项目下，这样方便使用和维护。 库表路由（ Table routing ） 库表路由顾名思义就是对库名和表名根据一定的路由规则进行转换。比如用户在上游多个 MySQL 实例或者 schema 有多个逻辑上相同的表，需要把这些表的数据同步到 TiDB 集群的同一个表中

作者：赵一霖 在 上篇文章 中，我们主要介绍了 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

在 TiDB 中，底层索引结构为 LSM-Tree，如下图： 开篇 世界级的开源分布式数据库 TiDB 自 2016 年 12 月正式发布第一个版本以来，业内诸多公司逐步引入使用，并取得广泛认可。 对于互联网公司，数据存储的重要性不言而喻。在 NewSQL 数据库出现之前，一般采用单机数据库（比如 MySQL ）作为存储，随着数据量的增加，“分库分表”是早晚面临的问题，即使有诸如 MyCat、ShardingJDBC 等优秀的中间件，“分库分表”还是给 RD 和 DBA 带来较高的成本； NewSQL 数据库出现后，由于它不仅有 NoSQL 对海量数据的管理存储能力、还支持传统关系数据库的 ACID 和 SQL，所以对业务开发来说，存储问题已经变得更加简单友好，进而可以更专注于业务本身。而 TiDB，正是 NewSQL 的一个杰出代表！ 站在业务开发的视角，TiDB 最吸引人的几大特性是： 支持 MySQL 协议（开发接入成本低）； 100% 支持事务（数据一致性实现简单、可靠）； 无限水平拓展（不必考虑分库分表）。 基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。 TiDB 事务和 MySQL 事务的差异 MySQL

作者：申砾 今年 1 月份，我们发布了 TiDB 3.0.0 Beta 版本 ，DevCon 上也对这个版本做了介绍，经过两个月的努力，今天推出了下一个 Beta 版本 3.0.0 Beta.1。让我们看一下这个版本相比于之前有什么改进。 新增特性解读 Skyline Pruning 查询计划正确性和稳定性对于关系型数据库来说至关重要，3.0.0 Beta.1 对这部分进行了优化，引入一个叫 Skyline Pruning 的框架，通过一些启发式规则来更快更准确地找到最好的查询计划。详细信息可以参考 这篇设计文档 。 日志格式统一 日志是排查程序问题的重要工具，统一且结构化的日志格式不但有利于用户理解日志内容，也有助于通过工具对日志进行定量分析。3.0.0 Beta.1 版本中对 tidb/pd/tikv 这三个组件的日志格式进行了统一，详细格式参见 这篇文档 。 慢查询相关改进 慢查询日志是常用于排查性能问题, 在 3.0.0 Beta.1 之前慢查询日志跟其他日志混合存储在同个日志文件，并且格式为自定义的格式，不支持使用 SQL 语句或工具对其进行分析，严重影响排查问题的效率。从3.0.0 Beta.1 版本开始 TiDB 将查询日志文件输出到单独的日志文件中（默认日志文件名为 tidb-slow.log ），用户可以系统变量或配置文件进行修改，同时兼容 MySQL

过去一年在 PingCAP 全力奔跑的同时，越来越多的小伙伴开始关注我们、了解我们，我们的团队也愈加庞大，我们也期待更多对我们感兴趣的小伙伴加入我们，跟我们一起做点有意义的事情。可能有些小伙伴对我司「神秘的招聘职位」感到茫然，对我们在做的事情也没有深入的了解，于是我们准备推出「PingCAP 招聘职位深度解读」系列文章，介绍 PingCAP 各个团队的小伙伴们现在在做什么、接下来的规划是什么、不同团队吸纳成员的核心需求是什么等等。 本篇将带大家速览我司各个研发团队的定位和分工，并回答一个热门问题「在 PingCAP 工作是什么样的体验？」 作为开源的新型分布式数据库公司，PingCAP 一直致力于探索并逐步解决分布式数据库领域的诸多问题 ，比如： 如何设计和实现世界前沿的分布式 SQL 优化器，让一个复杂的 SQL 查询变的无比轻快智能； 如何实现一致性同步的行列格式混合的 HTAP 架构，且 AP 业务对 TP 业务几乎无干扰； 如何在成千上万台集群规模的情况下，实现无阻塞的表结构变更操作，而不影响任何在线的业务； 如何实现高效的分布式事务算法，让 ACID 事务在大规模并发的分布式存场景下依然可以高效可靠； 如何基于 Raft 协议实现快速稳定的数据强一致复制和自动故障恢复，确保数据安全； 如何设计一个高效智能的调度器，负责对上百 TB 的数据进行调度，保证系统平稳运行；

年度最高规格的 TiDB 技术大会 海内外动态及成果的综合呈现 最新核心技术解读 多个成果首次亮相 2019 RoadMap 展望 14 位海内外基础架构领域技术大咖 8 个跨行业多场景的用户实战经验 1 小时 Demo Show 只为向你描述可以预见的 数据库的未来 1970 年关系模型的提出，在数据库领域如同打开了一扇创世之门，近半个世纪以来相关产品迅速迭代，新旧共生，我们试图洞悉其中规律，寻求一个问题的答案：什么是未来的数据库？ 然而谈到“未来”难免总是宏观而模糊，我们尝试用自己的方式来表达对未来的定义：年度规格最高的 TiDB 技术大会 TiDB DevCon 2019 正式开启。 我们将从技术理念开始，尽所能地向前眺望，分享我们所看到的，和即将付诸行动的一切探索。 时间：2019 年 1 月 19 日 地点：北京市 朝阳区 樱花园东街甲 2 号 北京服装学院内 中关村时尚产业创新园 二层 讲师介绍 会议议程 8:40 - 9:30 入场签到 9:30 - 9:50 Opening Keynote 刘奇，PingCAP 联合创始人兼 CEO 9:50 - 10:10 The Global Scale of TiDB (English) Morgan Tocker, PingCAP Senior Product and Community Manager 10:10 - 11