TiDB

作者：苏立 在之前的一篇文章 《TiDB 源码阅读系列文章（三）SQL 的一生》 中，我们介绍了 TiDB 在收到客户端请求包时，最常见的 Command --- COM_QUERY 的请求处理流程。本文我们将介绍另外一种大家经常使用的 Command --- Prepare/Execute 请求在 TiDB 中的处理过程。 Prepare/Execute Statement 简介 首先我们先简单回顾下客户端使用 Prepare 请求过程： 客户端发起 Prepare 命令将带 “?” 参数占位符的 SQL 语句发送到数据库，成功后返回 stmtID 。 具体执行 SQL 时，客户端使用之前返回的 stmtID ，并带上请求参数发起 Execute 命令来执行 SQL。 不再需要 Prepare 的语句时，关闭 stmtID 对应的 Prepare 语句。 相比普通请求，Prepare 带来的好处是： 减少每次执行经过 Parser 带来的负担，因为很多场景，线上运行的 SQL 多是相同的内容，仅是参数部分不同，通过 Prepare 可以通过首次准备好带占位符的 SQL，后续只需要填充参数执行就好，可以做到“一次 Parse，多次使用”。 在开启 PreparePlanCache 后可以达到“一次优化，多次使用”，不用进行重复的逻辑和物理优化过程。 更少的网络传输

如果只能用一个词来描述此刻的心情，我想说恍如隔世，这样说多少显得有几分矫情，或许内心还是想在能矫情的时候再矫情一次，毕竟当初做这一切的起因是为了梦想。还记得有人说预测未来最好的方式就是创造未来，以前看到这句话总觉得是废话，如今看到这一切在自己身上变成现实的一刻，感受是如此的真切，敲击键盘的手居然有点颤抖，是的，预测未来最好的方式就是创造未来。 还记得刚开始做的时候，只有很少的几个人相信这个事情可以做，毕竟难度比较高，就像有些户外旅行，只有方向，没有路。从零开始到 发布 1.0 版本 ，历时 2 年 6 个月，终于还是做出来了。这是开源精神的胜利，是真正属于工程师们的荣耀。这个过程我们一直和用户保持沟通和密切协作，从最早纯粹的为 OLTP 场景的设计，到后来迭代为 HTAP 的设计，一共经历了 7 次重构，许多看得见的汗水，看不见的心跳，也许这就是相信相信的力量，总有那么一群人顶着世俗的压力，用自己的信念和力量在改变世界。在这个过程中，质疑的声音变少了，越来越多的人从观望，到为我们鼓舞助威，帮助我们快速成长。特别感谢那些从 beta 版本开始一路相随的用户，没有你们的信任，耐心和参与，就没有今天的 PingCAP。 开心的时刻总是特别想对很多帮助和支持我们的童鞋们说声谢谢，没有你们就没有 PingCAP，特别感谢每一位项目的贡献者。也许你已经知道了，我们专门为你们定制了一面 荣誉墙

Zab 把节点分两种，Leader（主）和Follower（从）。 有一个主节点，所有写操作全部通过节点进行处理，如果一个从节点收到了一个写操作请求，就会转给主节点处理。 其他节点都是从节点，可以通过从节点进行读操作。 主节点通过选举得出，主节点失踪后，其他从节点自动开始选举新的主节点。 使用 Zookeeper 参考 Architecture of ZAB – ZooKeeper Atomic Broadcast protocol Raft Raft将一致性的问题分解为了三个问题： Leader Election：在Leader故障的时候，选出一个新的Leader。 Log Replication：Leader需要让日志完整地复制到集群内的所有服务器 Safety：如果某个服务器在特定的index提交了一个日志，那么不能有其它的服务器在相同的index提交日志，同一时刻只能保证有一个Leader。 发现主节点失踪一段时间后，向所有从节点向其他从节点发消息，让他们选自己为新的主节点； 还没参加选举的节点如果收到其他节点的选举请求，就选举自己收到的第一个节点，后面谁再请求自己支持选举，就告诉他们我已经支持另一个节点了 如果一个节点发现另一个节点得到的支持比自己多，也就开始无条件支持那个节点选举，同时让支持自己的节点也去支持它 如果一轮没选出来得到大多数节点支持的主节点

作者：沈泰宁 唐刘 许多人眼中的 PingCAP Talent Plan 可能就是 github.com/pingcap/talent-plan 这个项目，但从内容角度来说并不完整，这个 Repo 只是线上课程的内容，我们还有与其配套的线下课程。 本文将从课程设计的角度和大家聊一聊 PingCAP Talent Plan（TiKV 方向）课程，包括课程设计的逻辑、课程设计中遇到的困难，以及大家在学习过程中常见的问题和解答等。 PingCAP Talent Plan 是什么？ TiDB 是一个新型的开源分布式关系型数据库，目标是希望在大数据和云时代的新的业务需求下，帮助大家更好地解决数据大规模存储和实时计算的问题。我们听说很多同学跟我们反映他们很想参与到这些项目中去，但遇到了一些问题： 编程语言是参与项目的敲门砖。Golang 和 Rust 都比较新，需要一定的学习，是最直接的高门槛。 理论知识是深度参与的基础。从理论到实践有一道鸿沟，并不是这么容易跨越。 为了解决上述问题，我们启动了 PingCAP Talent Plan。目前课程主要分为两个方向，面向 SQL 优化器、分布式计算的 TiDB 方向 ，和面向大规模、一致性的分布式存储的 TiKV 方向 。课程大体分成线上学习阶段和线下学习阶段，线上课程的主要目标是帮助大家从编程语言开始，学习并掌握 Golang 和 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

本文作者是来自 TiNiuB 队的黄梦龙同学，他们的项目 TiQuery 在本届 TiDB Hackathon 2018 中获得了三等奖。 TiQuery 可以搜集诊断集群问题所需要的信息，包括集群拓扑，Region 分布，配置，各种系统信息，整理成结构化的数据，并在 TiDB 中支持直接使用 SQL 语言进行查询，开发和运维人员可以在 SQL 环境方便高效地进行问题诊断。 “距离 Hackathon 结束已经一个多星期了，感觉心情还是没有从激情中平复过来。不过由于我读书少，这时候好像只能感慨一句，黑客马拉松真是太好玩了……” 组队和选题 组队的过程有些崎岖，过程不细表，总之最后我们凑成了 4 人团队： 我（menglong）和阿毛哥是 PingCAP 内部员工，我在 TiKV 团队，目前主要是负责 PD 部分的。阿毛哥是 TiDB 组的开发，同时也是 Go 语言圈的大佬。 晓峰（ID 米麒麟）是大数据圈的网红，可能很多人都在各种社区或各种微信群偶遇过，另外他的公司其实也是上线了 TiDB 集群的客户之一。 胡争来自小米，是 HBase 的 committer，在分布式系统方面有丰富的经验，Hackathon 的过程中还顺便给 TiKV 集群的全局备份方案提了几个很好的建议，也是不得不服……他还有另外一个身份，是我们 TiKV 组员大妹子的老公

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)

经过半年时间的持续打磨，PingCAP University 迎来了一次重大升级，发布「培训课程 2.0」。 作为世界级的开源项目，经过四年的发展，TiDB 在越来越多的场景里落地，正逐渐被视为行业内的分布式数据库“事实标准”。随着用户社区技术服务体系的建立和优化，TiDB 社区力量日益壮大，在 GitHub 上已累计获得 Star 数近 2w，目前已有 300+ 用户将 TiDB 用于线上生产环境，超过 1400 家进行测试 ，在互联网、银行、证券、高端制造、大型零售等行业均有广泛应用。这些成果的背后都离不开社区用户的积极反馈和社区开发者的贡献。 “我们十分珍视这份信任，将继续把「用户至上」的观念和理念发挥到极致，与用户一起成长，并进一步赋能社区，培养更多的一流 NewSQL 人才 ，打造高质量高活跃度的 TiDB 技术社区。这是我们开办 PingCAP University 的初衷。”PingCAP 联合创始人崔秋表示。 PingCAP 于 2018 年底正式成立 PingCAP University，开设的 TiDB DBA 官方认证培训课程于 2019 年 1 月正式落地。目前，首批线下培训已经开展 10 余期，得到了社区伙伴的广泛响应。培训开办半年以来 PingCAP University 在实践中保持与学员的沟通，持续打磨课程，近期正式推出升级后的 2.0 版本。

TiDB 每一次微小进步都离不开广大社区小伙伴们的支持，但也有很多同学反映 TiDB 是一个非常复杂的分布式数据库系统，如果没有相关知识和经验积累，在参与之初难免会遇到各种问题。 因此我们决定全面升级 PingCAP Talent Plan 计划，为社区小伙伴开放一系列关于编程语言、数据库及分布式系统的线上课程，线上考核成绩优异的小伙伴还有机会参加为期 4 周的线下课程（免费的大神辅导班哦）！ 什么是 PingCAP Talent Plan PingCAP Talent Plan 是 PingCAP 为 TiDB 开源社区小伙伴提供的进阶式学习计划，以循序渐进的方式，让大家深入了解并掌握 TiDB/TiKV 相关知识及实操技能。 去年 11 月我们成功举办了 PingCAP Talent Plan 第一期 线下培训，如今 PingCAP Talent Plan 内容和形式全面升级，整个课程将分为线上&线下两个阶段，从语言层面开始，到数据库、分布式系统基础知识，再到 TiDB/TiKV 架构原理和源码，层层递进，最后让小伙伴们在操作实战中加深理解，掌握实操技能。 课程设计 整个课程分为两个方向，包括面向 SQL 引擎的 TiDB 方向 ，面向大规模、一致性的分布式存储的 TiKV 方向 。每个方向的课程都包含线上和线下两部分，且有相应的课程作业

最近我们扩展了 TiDB 表达式计算框架，增加了向量化计算接口，初期的性能测试显示，多数表达式计算性能可大幅提升，部分甚至可提升 1~2 个数量级。为了让所有的表达式都能受益，我们需要为所有内建函数实现向量化计算。 TiDB 的向量化计算是在经典 Volcano 模型上的进行改进，尽可能利用 CPU Cache，SIMD Instructions，Pipeline，Branch Predicatation 等硬件特性提升计算性能，同时降低执行框架的迭代开销，这里提供一些参考文献，供感兴趣的同学阅读和研究： MonetDB/X100: Hyper-Pipelining Query Execution Balancing Vectorized Query Execution with Bandwidth-Optimized Storage The Design and Implementation of Modern Column-Oriented Database Systems 在这篇文章中，我们将描述： 如何在计算框架下实现某个函数的向量化计算； 如何在测试框架下做正确性和性能测试； 如何参与进来成为 TiDB Contributor。 表达式向量化 1. 如何访问和修改一个向量 在 TiDB 中，数据按列在内存中连续存在 Column 内，Column 详细介绍请看： TiDB