TiKV

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

SOFA Stack S calable O pen F inancial A rchitecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:JRaftLab/ ，目前领取已经完成，感谢大家的参与。 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 SOFAJRaft ： https://gitee.com/sofastack/sofa-jraft 前言 SOFAJRaft-RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库，SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现，支持 Multi-Raft-Group。SOFAJRaft-RheaKV 集群主要包括三个核心组件：PD，Store 和 Region。本文将围绕 SOFAJRaft-RheaKV 架构设计，存储概览，核心模块，使用场景以及基于 Raft

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

众所周知，在对可用性要求极高的行业领域（比如金融、通信），分布式数据库需要跨地域的在多个数据中心之间建立容灾以及多活的系统架构，同时需要保持数据完整可用。但这种方式同时也带来了一些问题： 跨地域的网络延迟非常高，通常在几十毫秒左右，洲际间更能达到几百毫秒。 跨地域的网络专线带宽昂贵、有限，且难于扩展。 在今年 TiDB Hackathon 的比赛过程中，我们针对以上问题做了一些有趣的事情，并获得如下优化成果： 跨地域 SQL 查询，延迟下降 50%（图 1）。 跨节点消息数减半，即网络流量减半（图 2）。 <center>图 1 延迟对比</center> <center>图 2 网络流量对比</center> “Google Spanner 高性能事务和强一致特性（跨区域甚至跨洲），是每一个做多数据中心架构设计的工程师心中所向往的目标。虽然当前 TiDB 在多数据中心部署时的表现同 Google Spanner 还有明显的差距，但我们很高兴的看到“多数据中心读写优化”项目让 TiDB 向 Spanner 级别多数据中心能力迈出了坚实的一步。相信在社区小伙伴们的共同努力下，假以时日 TiDB 一定能够为大家带来 Google Spanner 级别的体验。” —— 孙晓光（知乎｜技术平台负责人） “在官方推荐的具备同城多活能力的同城三中心五副本，以及两地三中心五副本的部署方案中

作者：Yi Wu TiKV 是一个开源项目，我们一直都欢迎和感激开源社区对 TiKV 所作出的贡献。但我们之前对开源社区的合作主要是在代码审阅和散落在各种社交媒体的线下讨论，开发者并没有合适的途径去了解和影响 TiKV 的开发计划。怎么才能更好的帮助大家找到组织，更好地参与到 TiKV 的开发中来呢？我们的设想是搭建公开的平台，邀请对 TiKV 中特定领域感兴趣的开发者加入其中，与我们一起探讨和推进相应工作。Special Interest Group（SIG）就是这样的平台。 TiKV Engine SIG 是继 Coprocessor SIG 之后成立的第二个 TiKV SIG 社区组织，主要职责是对 TiKV 的存储引擎的未来发展进行讨论和规划，并进行相关开发和维护。 目前 TiKV 仅支持默认存储引擎 RocksDB，但是通过扩展接口，希望未来 TiKV 可以支持更多的存储引擎，我们也期待这部分工作可以得到社区的支持，在社区的讨论和贡献中得到更好的完善。此外，Engine SIG 也会对已有的存储引擎进行相关的开发和完善工作。 Engine SIG 的工作主要涉及的模块包括： Engine Trait： TiKV 中存储引擎的抽象层。 RocksDB：包括维护 TiKV 所使用的 RocksDB 分支，以及 rust-rocksdb 封装。 Titan：提供 KV

知乎技术平台团队负责人孙晓光有一个新的身份：开源分布式事务 Key-Value 数据库 TiKV项目的 Maintainer。Maintainer 是 TiDB/TiKV 开源社区的角色之一，是社区中较高级别的代码贡献者，项目的规划和设计者，拥有合并主干分支的权限。一般来说从开始贡献代码的 Contributor 成长为 Maintainer，最明显的变化是，对项目有更全局、深入的了解，对项目未来的发展也有独到、准确的见解。 孙晓光觉得，其实从 Contributor 到 Committer 再到最后成为 Maintainer 这个过程，最大的感受是自己逐渐融入到了 TiKV 社区中，真正有了归属感。今天我们就带着 TiDB/TiKV 社区伙伴们的期待，和孙晓光聊了聊，打探了一下他成为 Maintainer 的经历，以及对 TiKV 社区未来的想法。 初识：寻找原生的分布式存储方案 > 与 TiKV 项目初识，其实是带着明确的目标的。 孙晓光 2007 年毕业回国，当时国内刚开始做云，他进入一家做私有云的公司，从事私有云相关产品开发工作 7 年多时间，他坦言，这段工作经历让他个人积累了许多云相关底层系统的工作经验，这也是他对平台类技术比较感兴趣的核心原因。2017 年孙晓光加入知乎。 刚到知乎时，他负责已读服务的开发，知乎的存储层采用的还是 MySQL 分库分表技术方案。

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

作者：屈鹏 在 《TiKV 源码解析（二）raft-rs proposal 示例情景分析》 中，我们主要介绍了 raft-rs 的基本 API 使用，其中，与应用程序进行交互的主要 API 是： RawNode::propose 发起一次新的提交，尝试在 Raft 日志中追加一个新项； RawNode::ready_since 从 Raft 节点中获取最近的更新，包括新近追加的日志、新近确认的日志，以及需要给其他节点发送的消息等； 在将一个 Ready 中的所有更新处理完毕之后，使用 RawNode::advance 在这个 Raft 节点中将这个 Ready 标记为完成状态。 熟悉了以上 3 个 API，用户就可以写出基本的基于 Raft 的分布式应用的框架了，而 Raft 协议中将写入同步到多个副本中的任务，则由 raft-rs 库本身的内部实现来完成，无须应用程序进行额外干预。本文将对数据冗余复制的过程进行详细展开，特别是关于 snapshot 及流量控制的机制，帮助读者更深刻地理解 Raft 的原理。 一般 MsgAppend 及 MsgAppendResponse 的处理 在 Raft leader 上，应用程序通过 RawNode::propose 发起的写入会被处理成一条 MsgPropose 类型的消息，然后调用 Raft::append_entry 和 Raft:

作者：骆迪安 上一篇 《 TiKV 源码解析系列文章（十四）Coprocessor 概览 》讲到了 TiDB 为了最大化利用分布式计算能力，会尽量将 Selection 算子、聚合算子等算子下推到 TiKV 节点上。本文将继续介绍 Coprocessor 中表达式计算框架的源码架构，带大家看看 SQL 中的表达式是如何在 Coprocessor 中执行的。 什么是表达式 比如说我们有这个 SQL 作为例子： SELECT (count * price) AS sum FROM orders WHERE order_id < 100 其中 order_id < 10 就是一个表达式，它有一个列输入参数： order_id ，输出： Bool 。 RPN 表达式 因为 TiDB 下推的是树状结构表达式，所以我们需要选择一种树的遍历方式， 这里 Coprocessor 选择了由下而上递推的 RPN（逆波兰表示法）。RPN 是树的后序遍历，后序遍历在每个节点知道自己有几个子节点的时候等价于原本的树结构。 比如说我们有一个数学算式 2 *（3 + 4）+ 5 ： 由于数学上习惯写法是中序遍历，我们通常要加上括号消除歧义（比如加减和乘除的顺序）。通过把操作符后移 我们得到 RPN：2 3 4 + * 5 + ，这样我们无需括号就能无歧义地遍历这个表达式： 执行 RPN

作者介绍：崔灿，京东云产品研发部专家架构师，目前主要负责京东云对象存储产品的工作。 京东云对象存储是在 2016 年作为公有云对外公开的，主要特点是可靠、安全、海量、低成本，应用于包括一些常用的业务场景，比如京东内部的京东商城视频/图片云存储，面向京东云公有云外部的开发者的服务，和面向企业的私有云服务，甚至混合云服务。 本文将介绍京东云对象存储服务的架构演进，以及迁移到 TiKV 的经验。 一、对象存储简介 <center>图 1 什么是“对象”</center> 首先举例说明一下这里的“对象 (Object)”概念。比如我们把一张照片当作一个“对象”，除了照片本身的二进制数据，它还应该包含一些元信息（照片数据长度、上次修改时间等）、涉及用户的数据（拍摄者、拍摄设备数据等）。对象存储的特点是这些数据不会频繁地修改。 如果是数量比较少的图片存储，我们可能会用类似 LVM 之类的东西，把一个节点上的多个磁盘使用起来，这种方法一般适用于数量级在 1M ~ 10M 的图片。随着业务的增长，图片会越来越多甚至有视频存储，因此我们采用分布式文件系统来存储，这种方法是基于 DFS 的架构（如下图所示）。 <center>图 2 如何存储对象（数据量 1B）</center> 这种方法的前提是单机容量受限，必须把数据放在多台机器上存储，并且用一个或多个独立的 node 存储元数据