TiDB

Welcome ! The Builders ! 这是一篇招募 TiDB 生态宇宙创造者、工程师、看管者的文章。 众所周知，PingCAP 一直坚定地拥抱「开源」，“自由灵魂”、“人文主义” 的信仰也深植每个 PingCAPer 的内心，我们无时无刻不在尝试扩展 TiDB 开源生态宇宙的版图，同时也希望借此吸引来更多志同道合的朋友。 经过 5 年的迭代，TiDB 内核逐渐趋于稳定和强大，未来也会继续朝着数据库领域的先进技术标准前进。同时，构建一个基于 TiDB 的、具有生命力的生态系统也是不容忽略的使命。这也正是我们 Ecosystem Tools（E.T.）团队的重要职责所在。下面简单介绍我们重点研发的几个 TiDB 生态工具的发展历程和规划，希望志同道合的小伙伴能加入我们，一起玩转 TiDB 开源生态宇宙！ CDC Change Data Capture（CDC），是用来识别、捕捉、交付 TiDB/TiKV 上数据变更的工具系统 。CDC 作为 TiDB 的数据出口，在商业和生态上有着非常重要的地位，作用包括但不限于: 构建 TiDB 主从、灾备系统；链接到其他异构数据库；自定义业务逻辑。 ticdc 是基于 TiKV 实现的 row data changed capture： 具备可随 TiKV 集群规模扩展的处理能力； 在不依赖 TiDB 事务模型实现的基础上还原事务的能力

3 月，跳不动了？>>> 关系型数据库的 DBA 日常肯定遇到过这样的一种场景： SQL 执行计划选择错误，这类问题的危害是很大的，常常导致业务突然卡顿，数据库过载等不良后果。 举个例子，假设我们有这么一张表： 其中，姓名和性别这两列有索引。我们设想一下，在这张表上，我们进行下面一条查询： SELECT * FROM t WHERE 姓名='小明' and 性别='男' 正常情况下，SQL 优化器内部会通过采样等手段，得到姓名和性别这两个索引的数据区分度，在这个场景下，大多数时候，「姓名」都是一个更有区分度的索引，所以优化器会选择姓名进行查询就能过滤掉大量的行。 但是，我们设想一个比较极端的情况，突然这个表中写入了大量的“女性小明”： 也就是会出现这样一种情况：对这条语句来说，使用「姓名」这个索引区分度变得不高，因为有大量的同名小明，但是「性别」这个索引却非常合适（只有一个男性小明）。 如果这个时候 SQL 优化器仍然选择了姓名的索引， 在业务中就会出现一条本来跑得好好的 SQL 突然变成了慢查询。 由于 TiDB 作为一个关系型数据库，而且优化器也是基于代价的优化器，通常基于代价的优化器对于数据的采样很难做到瞬时，尤其是数据量特别大表来说，总是有可能出现数据的分布随着业务的变化发生突变，即时采样做到实时，不仅仅是索引的选择，也包括 JOIN 方式的选择，JOIN 的顺序等

3 月，跳不动了？>>> 本文转载自公众号 51CTO技术栈 。 **作者介绍：**贺磊，360 数据库运维资深工程师，《MongoDB 运维实战作者》，知名论坛 MySQL 版主，51CTO 博客之星，闲暇之余，喜欢将部分案例写成博客，累计访问量过百万。 我先说几个最让你兴奋和开心的点吧： 在 TiDB 里，你完全不用担心磁盘容量的问题。 在 TiDB 里，原生支持 Online DDL，你完全不用担心第三方改表工具改表出现各种 Bug 的问题，相信用开源工具改过上 T 级别表的同学都遇到过或多或少的各类 error。 在 TiDB 里，加列、主键扩容字段都是秒级的，比如我刚刚就刚对一张 19 亿的表加完了字段，1 秒完事，这在 MySQL 里要 8.0 才可以，而且还要求列在最后才行。 在 TiDB 里，你会发现 count(*) 惊人的快，一张近 20 亿的表 coun(*) 大概在 1 分钟完事儿，当然，这取决于你的 KV 数量和磁盘性能。 在 TiDB 里，从 MySQL 迁移将变得简单，图形化一键迁移，爽不爽？ 在 TiDB 里，绝大多数情况你会发现比单机 MySQL 有更好的性能，当然也不排除一些例外，例如 enum 这样奇葩的字段类型。 在 TiDB 里......您且往下看，我慢慢和您说。 使用背景 60 云平台对 360 集团各大业务线均有提供服务支持

3 月，跳不动了？>>> 2018 年 11 月 30 日，TiDB 发布 2.1 GA 版。相比 2.0 版本，该版本对系统稳定性、性能、兼容性、易用性做了大量改进。 TiDB SQL 优化器 优化 Index Join 选择范围，提升执行性能 优化 Index Join 外表选择，使用估算的行数较少的表作为外表 扩大 Join Hint TIDB_SMJ 的作用范围，在没有合适索引可用的情况下也可使用 Merge Join 加强 Join Hint TIDB_INLJ 的能力，可以指定 Join 中的内表 优化关联子查询，包括下推 Filter 和扩大索引选择范围，部分查询的效率有数量级的提升 支持在 UPDATE 和 DELETE 语句中使用 Index Hint 和 Join Hint 支持更多函数下推： ABS / CEIL / FLOOR / IS TRUE / IS FALSE 优化内建函数 IF 和 IFNULL 的常量折叠算法 优化 EXPLAIN 语句输出格式, 使用层级结构表示算子之间的上下游关系 SQL 执行引擎 重构所有聚合函数，提升 Stream 和 Hash 聚合算子的执行效率 实现并行 Hash Aggregate 算子，部分场景下有 350% 的性能提升 实现并行 Project 算子，部分场景有 74% 的性能提升 并发地读取 Hash Join

3 月，跳不动了？>>> TiDB 是由 PingCAP 开发的分布式关系型数据库，今天我们很高兴地推出 TiDB 2.1 正式版，提供更丰富的功能、更好的性能以及更高的可靠性。 回顾 2.0 版本 今年 4 月份我们发布了 TiDB 2.0 版本 ，提升了稳定性、性能以及可运维性，这个版本在接下来的半年中得到了广泛的关注和使用。 迄今为止 TiDB 已经在 数百家用户 的生产环境中稳定运行，涉及互联网、游戏、金融、保险、制造业、银行、证券等多个行业，最大集群包含数百个节点及数百 TB 数据，业务场景包含纯 OLTP、纯 OLAP 以及混合负载。另外，既有使用 TiDB 当做关系数据库的场景，也有只用 TiKV 作为分布式 Key Value 存储的场景。 这几个月，在这些场景中，我们亲历了跨机房容灾需求、亲历了几十万级别的高吞吐业务、亲历了双十一的流量激增、亲历了高并发点查、高并发写入与上百行复杂 SQL 的混合负载、见到过多次的硬件/网络故障、见到过操作系统内核/编译器的 Bug。 简而言之，我们的世界充满了未知，而分布式关系型数据库这样一种应用广泛、功能丰富且非常关键的基础软件，最大的困难就是这些“未知”。在 2.1 版本中，我们引入了不少新的特性来抵御这些未知，适配各种复杂的场景，提升性能和稳定性，帮助我们的用户更好地支撑复杂的业务。 新特性 更全面的 Optimizer

3 月，跳不动了？>>> 作者 | Eric Li (壮怀) 阿里巴巴云原生存储负责人 引言 随着云原生应用对可迁移性、扩展性和动态特性的需求，对云原生存储也带来了相应的密度、速度、混合度的要求，所以对云存储基本能力之上又提出了在效率、弹性、自治、稳定、应用低耦合、GuestOS 优化和安全等方面的诉求。参考 《云原生存储和云存储有什么区别？》 新的企业负载／智能工作负载容器化、迁云、存储方面遇到的性能、弹性、高可用、加密、隔离、可观测性及生命周期等方面的问题，不但需要存储产品层次的改进，还需要在云原生的控制／数据平面的改进，推进云原生存储和云存储的演进。下文将分别介绍一下问题场景及问题，探讨可行的解决方案，最终可以得出云原生存储、云存储目前可以做什么和未来还需要做什么。 存储性能 长时延增加 场景 高性能计算场景中，集中处理批量数据，通过容器集群，同时启动数千 Pod，弹出数百 ECS 对共享性文件系统读写。 问题 重负载终负载下时延增加，高延迟毛刺增多，读写稳定性不足。 解决方案 分散负载到多文件系统，通过容器编排分散 IO 到多文件系统 存储产品的盘古 2.0 改造 集中式高吞吐写对共享存储池冲击 场景 高性能计算场景中，集中处理批量数据，10Gbps 读写请求进入同一存储集群。 问题 同一存储集群中的带宽挤占，造成访问质量下降。 解决方案 分散负载到多文件系统和多个存储集群

3 月，跳不动了？>>> “SQL at SCALE”（出自 PingCAP 官网 ）是我们对 TiDB 的一个精简概括，而我们 TiDB SQL Engine Team 正是负责这 3 个单词中的 “SQL” 部分，其重要性可见一斑。SQL 在数据库中的大致处理流程可以简短概括为查询优化和执行，这期间涉及到 SQL Parser、优化器、统计信息和执行引擎等模块，他们就是 TiDB SQL Engine Team 目前所负责的模块。接下来我会用简短的篇幅向大家介绍 SQL Engine 的背景知识，以及我们在做的事情，面临的挑战等。 关于查询优化 优化器是 SQL 引擎的大脑，负责查询优化。查询优化的主要工作概括起来很简单：搜索可行的执行计划，从中挑一个最好的。但要做好这两件事却是整个分布式数据库中最难的地方。 1979 年 Selinger 发布了 “ Access Path Selection in a Relational Database Management System ”，正式拉开了 Cost Based Optimization 的帷幕，这篇论文也被视为 CBO 优化器的圣经。在这之后陆续出现了 Starburst （1988 年）， Volcano Optimizer Generator （1993 年）和 Cascades Framework （1995 年）

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

3 月，跳不动了？>>> 如果说在 TiDB 3.0 中，悲观锁是 “千呼万唤始出来，犹抱琵琶半遮面”。那么在 TiDB 4.0 中，悲观锁在经历了市场与时光的考验后，无论是性能还是稳定性都能够 “轻拢慢撚抹复挑，初为《霓裳》后《六幺》”。TiDB 4.0 悲观锁，欢迎大家尝鲜与反馈。本文将从使用者的角度，介绍悲观锁的使用与注意事项，主要分为以下几方面： 白话悲观锁 TiDB 悲观锁的使用和常见现象 TiDB 悲观锁与 MySQL 的兼容性 未来展望 白话悲观锁 自新年以来，口罩作为 2020 年最时尚的年货，变得异常难买，为了能够顺利抢到口罩，我是夜夜辗转难眠，日日盯着各大网站下单，通过这个过程，倒也总结出了各大平台的的购物体验： A 类网站：加购物车 飞快 ，成功加入购物车加后，下单 不一定 有库存。 B 类网站：加购物车 有点卡 ，成功加入购物车后，下单 一定 有库存。 作为互联网研发从业者，聪慧如你，一起来思考这两类网站是如何实现加购物车这一逻辑？ A 类网站乐观地假设不存在其他客户同时抢这批口罩，库存代表没下单的库存，给了客户非常积极的体验，我们称这种行为下加购物车时，使用了乐观锁。 这种乐观锁使用的体验是：前期加购物车一时爽，最终下单可不一定爽。 当存在其他网友同时跟你抢这批口罩下单时，可能会遇到以下问题： 提交不一定成功。 冲突需要重试。（其他人先下单，库存变化

3 月，跳不动了？>>> 2020 年 2 月，TiKV 项目迎来了一位新晋 Committer —— 庄天翼（GitHub ID：TennyZhuang），他 2018 年毕业于清华大学，目前在旷视科技担任分布式存储开发工程师，平时爱看动漫，工作之余也喜欢写一些代码，实现自己的想法。前天，我们“正儿八经”地采访了庄天翼同学，在互相努力憋笑中，愉快地掉落了以下文字…… 传说中的“天才少年” 天翼并不是普通意义上的计算机“天才少年”。 虽然他在大四时和队友一起拿了 CCPC（中国大学生程序设计竞赛）区域赛金牌，但他第一次接触编程已经是高中了，当时并没有深入研究编程，只是觉得学起来挺喜欢。在拿到化学竞赛金牌并保送清华后他也没有选择计算机专业，而是在材料学院就读，直到大三才正式转专业到了软件学院。 为了顺利转系到软件学院，他利用课余时间修了大一和大二的计算机课程。得力于之前给学院老师留下的深刻印象，大三一开学他就成为软件学院的助教，协助老师设计课程并分享自己做这门课程的心得。 天翼说突破舒适区，学习新的东西是一件很有成就感的事。 “大三时学院有一门 Haskell 课程，当时作业分级，我完成了最高难度的题并且做了拓展，写了一个比较完整的 scheme 解释器，这门课拿了满分。虽然现在看来没那么厉害，但当时觉得很有成就感。” 理解“开源社区” 与开源结缘 当被问到第一次是怎么接触到开源时