TiDB

我感到自豪，因为我取得了第一个胜利，我毫不怀疑胜利是会接踵而至的。我做到了第一件做不到的事情，我也可以接着做下去。——王小波《我在荒岛上迎接黎明》 TiDB 的设计灵魂，是让优雅灵活的架构充满无限可能性。从大规模业务场景中稳定使用的 TiDB 2.0 版本，到这一次备受关注的 3.0，我们持续地在倾听、修正、尝试，并获得一次又一次验证。距离年初公布 TiDB 3.0 beta 版本，已经过去了大半年，这期间我们对各方面进行了测试和优化，也看到有第一梯队用户在业务中体验了 3.0 的新特性。很多小伙伴好奇我们当时承诺的 TiDB 3.0 稳定性 / 易用性 / 高性能 / 新功能，都兑现得怎么样了？ 今天正式剧透一波：TiDB 3.0 GA 版本将在本月底正式发布！借此机会，为了让更多的社区伙伴能够近距离与我们展开交流，并快速 Get 3.0 GA 的技术细节和正确使用姿势， 我们启动「TiDB TechDay 2019 全国巡讲」，打破「一年一城」的传统，巡回北京、上海、成都、深圳、武汉、杭州 6 座城市，用一整天的时间为当地朋友深入拆解 TiDB 3.0 以及展示今年技术层面的各个大招 ：从 TiDB 最新的 OLAP 架构，到云原生 TiDB demo、TiKV 性能大幅提升等等。各地用户伙伴也会一起交流分享 TiDB 实践经验，另外关于全球开源社区运营，我们又有了新的想法

我司 Engineering VP 申砾在 TiDB DevCon 2019 上分享了 TiDB 产品进化过程中的思考与未来规划。本文为演讲实录上篇，重点回顾了 TiDB 2.1 的特性，并分享了我们对「如何做一个好的数据库」的看法。 <center>我司 Engineering VP 申砾</center> 感谢这么多朋友的到场，今天我会从我们的一些思考的角度来回顾过去一段时间做了什么事情，以及未来的半年到一年时间内将会做什么事情，特别是「我们为什么要做这些事情」 。 TiDB 这个产品，我们从 2015 年年中开始做，做到现在，三年半，将近四年了，从最早期的 Beta 版的时候就开始上线，到后来 RC 版本，最后在 2017 年终于发了 1.0，开始铺了一部分用户，到 2.0 的时候，用户数量就开始涨的非常快。然后我们最近发了 2.1，在 2.1 之后，我们也和各种用户去聊，跟他们聊一些使用的体验，有什么样的问题，包括对我们进行吐嘈。我们就在这些实践经验基础之上，设计了 3.0 的一些特性，以及我们的一些工作的重点。现在我们正在朝 3.0 这个版本去演进，到今天早上已经发了 3.0 Beta 版本 。 TiDB 2.1 首先我们来讲 2.1，2.1 是一个非常重要的版本，这个版本我们吸取了很多用户的使用场景中看到的问题，以及特别多用户的建议

PingCAP Talent Plan 学习通道自开通以来，收获了海内外小伙伴的密切关注，有 100 余名小伙伴参与到线上课程的学习中，第二期线下课程也于 5 月中旬圆满落幕。结合大家的意见，我们对 Talent Plan 的课程做了一些优化，并推出 Talent Plan 暑期特别企划，线上课程和线下课程都增加了一些新的元素～大家快来接收这一波“小惊喜”吧！ 线上课程 1. Practical Networked Applications in Rust 全面开放 我们发现很多开发者都愿意参与 TiKV 的研发，但通常都会遇到两个困难，第一是不会 Rust 语言，因为这门语言的门槛实在太高了，第二是没有分布式数据库相关的理论知识，不知道如何用 Rust 写一个分布式高性能服务。虽然现在市面上有很多的 Rust 教程，但大多数是集中在语言本身的教学上面，所以我们决定在它们的基础上，专门推出一套新的 Rust 培训课。基于这方面的考虑， Rust 核心作者 Brian Anderson 对 Rust 课程进行重新设计，推出 Practical Networked Applications in Rust （ https://github.com/pingcap/talent-plan/tree/master/rust ），并向社区小伙伴全面开放 。 通过这门课程，大家不仅能学到

前面两期我们介绍了 TiDB 团队 和 TiKV 团队 ，颇受好评，今天我司数据库专家 马晓宇 老师将为大家介绍 PingCAP 最具活力的团队—— AP（Analytical Product） 团队，如果你对亲手打造酷炫的大数据分析产品感兴趣，就快快投个简历来和我们聊聊吧～ 大家都知道 TiDB 是一款定位于在线事务处理/在线分析处理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品， 加强和补齐 HTAP 中的 AP 环节是这个团队的重要工作职责 。 TiDB 的 Coprocessor（协处理器）架构使得大量计算可以并行进行，例如由协处理器进行谓词过滤，预聚合等等，这样一来很多计算被众多 TiKV 资源分担，并且汇聚到 TiDB 的计算将大大减少，由此虽然 TiDB 本身仍然是单机，却可以很大程度满足 AP 需求。 不过这并不是 AP 团队工作的全部。 TiFlash TiFlash 是一个相对独立完整的分析型数据库产品。独立，说明历史包袱会比较小，可以尝试各种可能的设计；同时，我们也希望它尽可能完整，能承担一个分析型数据库应有的职责 。这个项目需要熟悉 C++，熟悉分布式系统的 Infra 工程师同学们入伙。 Why 也许您看了 TiDB / TiSpark 的架构，会有个疑问。TiDB

TiDB Hackathon 2019 已经开放报名 1 个多月啦，之前抓耳挠腮想不到选题、组不到队友的伙伴们都渐渐成队，并开始做赛前准备了。为了刺激围观同学的“灵感小火花”，我们今天又扩充了一波选题，如果大家还不知道做什么项目的话，择日不如撞日，今天就锚定一个果断报名参赛吧！ 另外，参赛选手在赛前准备阶段对选题有任何疑问，都可以联系 TiDB Robot（微信号：tidbai），导师团将针对性地进行赛前辅导，帮大家扫清一些知识盲区哦～ 参考选题 性能提升 提升 TiDB 的内存复用（可以考虑使用 sync.pool） 用 unistore 替换 mocktikv，跑出单机 TiDB 的极限性能，同时加快跑单元测试 易用性提升 Key visualizer for TiKV，相关资料: https://cloud.google.com/blog/products/databases/develop-and-deploy-apps-more-easily-with-cloud-spanner-and-cloud-bigtable-updates 热点索引统计 使用 SQL 获取集群信息 稳定性提升 自适应 SQL 引擎 提高 Cost 估算的精度 基于历史的查询优化 SQL Plan Management 之 Plan History 结合 https://github.com

2017 年 10 月，国内领先的中立云计算厂商 UCloud 与国内开源分布式 NewSQL 数据库 TiDB 团队 PingCAP 正式达成合作，双方将联手在 UCloud 全球数据中心逐步推出新一代 TiDB 的云端版本——Cloud TiDB。 截至目前，UCloud 已在北京、上海、广州、浙江、香港、台北、高雄、首尔、东京、新加坡、曼谷、洛杉矶、华盛顿、法兰克福、莫斯科全球 15 个地区部署了 21 个云数据中心，可有效覆盖中国大陆、港澳台、日韩、东南亚、北美、欧洲地区用户，为国内及“出海”企业提供优质的云计算服务。随着 Cloud TiDB 上线，UCloud 的数据库产品线得到了进一步丰富，能为广大用户提供更多数据库解决方案，以应对大数据时代的多元业务需求。 作为国内首家开源的新型分布式数据库公司，PingCAP 一直致力于基础架构领域的前沿技术创新实现。其独立研发的分布式数据库产品 TiDB 是一款定位于在线事务处理/在线分析处理（HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品，现已被数十家不同行业的领先企业应用在实际生产环境，涉及互联网、游戏、金融、政府、电信、制造业等多个行业，因此多行业场景的技术适配能力使产品与云平台结合后具有了更多可能性。 此次双方联手发布的 Cloud TiDB 是以

去年年底 我们启动了 PingCAP University 培训认证计划，获得了社区伙伴们的广泛响应。PingCAP University 已经开展五期线下培训，百余名学员在 PingCAP 北京&上海 Office 参加了为期 4 天的 PCTP 线下培训，大家表示 干货密度相·当·高 。 <center>线下培训部分学员合影</center> TiDB 社区的日益壮大，除了得益于所有开发者们的贡献，更离不开用户在使用过程中不断积极反馈的力量。随着 TiDB 应用场景的迅速扩展，我们听到了越来越多的用户在使用上的反馈，由此我们也建立了良性的用户社区技术服务体系。在为大家提供技术服务的同时我们也希望「授人以渔」，通过一套完整的官方技术培训课程，让更多的社区伙伴掌握 TiDB 部署、运维及调优等实操技能，提高自主响应和解决问题的速度，同时帮助社区伙伴们拓展技术前沿视野，迅速成长，壮大 TiDB 社区人才队伍。 接下来，我们将继续拓展 PingCAP University 培训认证计划的广度和深度，让更多社区伙伴有机会参与进来，与 TiDB 社区一起共同成长。今天先公开一个 “小惊喜” ： PingCAP University 课程网站已正式上线，并全部免费开放，内容包括 TiDB 基础知识及架构、管理及使用，TiDB 生态工具架构及原理，以及 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

　　在一个分布式环境中，我们习惯使用GUID做主键，来保证全局唯一，然后，GUID做主键真的合适吗？ 　　其实GUID做主键本身没有问题，微软的很多项目自带DB都是使用GUID做主键的，显然，这样做是没有问题的。然而，SQL Server默认会将主键设置为聚集索引，使用GUID做聚集索引就有问题了。很多时候程序员容易接受SQL Server这一默认设置，但无序GUID做聚集索引显然是低效的。 　　那么，我们在项目中如何避免这一问题呢？ 　　主要的思路还是两方面——方案一，选择合适的列作为聚集索引；方案二，使用有序的主键。 1 方案一，选择合适的列做聚集索引 　　选择原则很简单——字段值尽量唯一，字段占用字节尽量小，字段值很少修改，字段多用于查询范围数据或排序的数据。 　　之所以是根据以上原则选择，主要还是基于B+树数据索引问题，这部分内容都比较基础，这里就不举例验证了，以上原则还是比较公认的，即便读者不太理解其中原理，也请记住这一选择规则。 　　常见的备选项——自增列（Id）和时间列（CreateTime）。 　　聚集索引的最大用处就是帮助范围查询快速定位，从而减小数据库IO的消耗来提升查询效率。对于范围查询我们更多的应用在自增列和时间列上，因为这两列本身反应了数据的创建顺序，符合多数范围查询的场景需要。 　　大部分时候，我们仍然可以使用GUID做主键，只需要重新设置聚集索引就行。

作者：崔一丁 到今天为止，“成为 Contributor 系列”已经推出了 “ 支持 AST 还原为 SQL ”，“ 为 TiKV 添加 built-in 函数 ”，“ 向量化表达式 ”等一列活动。 这一次借着 TiDB 优化器重构的契机，我们将这个系列再向着数据库的核心前进一步，挑战一下「为 TiDB 的优化器增加优化规则」，带大家初步体验一下可以对查询的执行时间产生数量级影响的优化器的魅力。 众所周知优化器是数据库的核心组件，需要在合理的时间内寻找到一个合理的执行计划，确保查询可以稳定快速地返回正确的结果。最初的优化器只有一些启发式的优化规则，随着数据量和业务的变化，业界设计出了 System R 优化器框架来处理越来越多的复杂 SQL 查询。它将查询优化分为逻辑优化和物理优化两个阶段，逻辑优化根据规则对执行计划做等价变形，物理优化则根据统计信息和代价计算将逻辑执行计划转化为能更快执行的物理计划。目前 TiDB 优化器采用的也是该优化器模型。 虽然 System R 优化器框架大大提升了数据库处理复杂 SQL 的能力，但也存在一定缺陷，比如： 扩展性不好。每次添加优化规则都需要考虑新的规则和老的规则之间的关系，需要对优化器非常了解的同学才能准确判断出新的优化规则应该处在什么位置比较好。另外每个优化规则都需要完整的遍历整个逻辑执行计划，添加优化规则的心智负担和知识门槛非常高。