TiKV

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

作者：沈泰宁 唐刘 许多人眼中的 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 是一个非常复杂的分布式数据库系统，如果没有相关知识和经验积累，在参与之初难免会遇到各种问题。 因此我们决定全面升级 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 方向 。每个方向的课程都包含线上和线下两部分，且有相应的课程作业

作者介绍 ：孙晓光，知乎技术平台团队负责人，负责建设知乎在线和离线的基础设施平台，为业务开发提供统一的基础设施。曾多年从事私有云相关产品开发工作，关注云原生技术，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

作者：施闻轩 在 《TiKV 源码解析系列文章（十二）分布式事务》 中，我们介绍了如何在满足事务特性的要求下进行数据写入。本文将介绍数据读取的流程。由于顺序扫（Forward Scan）比较具有代表性，因此本文只介绍顺序扫的流程，而不会介绍点查或逆序扫。点查是顺序扫的简化，相信读者理解了顺序扫的流程后能自己想出点查的实现，而逆序扫与顺序扫也比较类似，主要区别在于从后向前扫，稍复杂一些，相信大家在阅读本文后，也能自己对照着代码读懂逆序扫的实现。 数据格式 首先回忆一下事务写入完成后， 在 RocksDB 层面存储的具体是什么样的数据 ： CF RocksDB Key RocksDB Value Lock user_key lock_info Default {user_key}{start_ts} user_value Write {user_key}{commit_ts} write_info 其中： 为了消除歧义，约定 User Key ( user_key ) 指 TiKV Client（如 TiDB）所写入的或所要读取的 Key，User Value ( user_value ) 指 User Key 对应的 Value。 lock_info 包含 lock type、primary key、timestamp、ttl 等信息，见 src/storage/mvcc/lock

前面两期我们介绍了 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

作者介绍 ：孙晓光，知乎技术平台团队负责人，负责建设知乎在线和离线的基础设施平台，为业务开发提供统一的基础设施。曾多年从事私有云相关产品开发工作，关注云原生技术，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

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