TiKV

今早开电脑，看到老板深夜的留言瑟瑟发抖...... 老板：大妹子啊，最近忙不？ （俺是左思右想搔头摸耳揣摩老板啥意思，想来老板是耿直 Boy, 这次居然没有直接说要干啥，自行脑补了 N 多场景，最后一咬牙还是如实回答。） 俺：大家都忙得不行了，这么说吧，小童木桌上那几个女朋友都快不认识了。 老板：这样不行啊，还是要有生活呀。 俺：是啊是啊，能少派活多发钱么？ 老板：奖金加，活得干，首要招人招人，尽快交个招聘贴上来，优先级：紧急重要。 俺（呃呃。。都说忙死了，又加活）：…… 这大白天的，作为一个码农，不敲 Bug 不看 PR ，绞尽脑汁想这新任务怎么完成： 吹牛这种肯定指不上俺了，八卦倒是俺的强项，但老板不让讲别人（他）的八卦，看来只能从自己的八卦开始了。 来到 PingCAP 之前，作为一个自诩放荡不羁爱自由的 · 伪 · 文艺青年，去过几家大公司，也去过一家创业公司，结局都是待了一年半载就觉得无趣无聊 & 不够激情 & 浪费青春，然后匆匆跑路。 来到 PingCAP 之后，虽然吐槽依旧很多但……身体却很诚实！貌似还真没有想过要主动离开，连我自己都奇怪，这三年都过去了（孩子都生完了），俺怎么还赖在这里…… 数一数 PingCAP TiKV 吸引我的五大理由 遇到一个好老板？ 好老板的定义，就跟好老公似的，萝卜青菜各有所爱，平心而论，TiKV 部门的老板对俺而言是个好老板

随着越来越多的同学选择使用 TiDB， TiDB 的易用性收到越来越多用户的关注，让 TiDB 变得更好用就显得越来越重要。为了能够打造一个大家心中的真正好用易用的 TiDB，我们启动了 “ 我的 TiDB 听我的 ” 活动，并特意征求了 TiDB User Group(TUG) 专家组的意见，选择出了 20 个最重要、最迫切的易用性需求。 三月初，围绕着这 20 个呼声最高的需求，我们在社区启动了 TiDB 易用性挑战赛 。赛事开启后，大家可是百花齐放，百家争鸣。目前赛程已经过半，我们先来看看战绩吧！ 首先，我们看一下本次赛季参与的团队情况： 截止今日，我们一共收到 93 支队伍 报名（包括个人参赛队员和多人组建团队），共计 136 位选手参赛 。目前的积分排行榜上已有 5 支队伍积分超过 2000： 目前个人参赛者成绩比较突出 ，其中： 状元： gauss1314 （个人参赛者），针对 TiDB 进行了易用性优化。 榜眼： SSebo （个人参赛者），针对 TiKV 进行了易用性优化。 希望这两位同学能够再接再厉，争取突破语言和项目边界，能够同时造福多个 Repo，也希望其他团队也能早日超越这两位同学，咱也争个状元来玩玩 最后，我们来看看本赛季整体任务完成情况： 如上图所示，蓝色表示被认领的任务数，红色的表示已经完成的任务数，也就是说，截止发稿时， 共有 215 个任务被认领

　　因为数据磁盘问题，最近进行了更换库，所以决定写关于这方面的专题的博客，博客信息参考的官方文档。 一、分布式数据库使用背景 　　随着互联网的飞速发展，业务量可能在短短的时间内爆发式地增长，对应的数据量可能快速地从几百 GB 涨到几百个 TB，传统的单机数据库提供的服务，在系统的可扩展性、性价比方面已经不再适用。比如MySQL数据库，缺点是没法做到水平扩展。MySQL 要想能做到水平扩展，唯一的方法就业务层的分库分表或者使用中间件等方案。但是，这些中间层方案也有很大局限性，执行计划不是最优，分布式事务，跨节点 join，扩容复杂等。 二、分布式数据库TiDB简介 　　TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。。 TiDB 具备如下特性： 高度兼容 MySQL 　　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB

此文目的 由于本人最近已经成为TiDB的粉丝，所以就开始各种研究TiDB的源码，研究源码这个事情，首先就需要在自己电脑上不断的调试及修改。TiDB本身的代码是非常容易编译和调试的，但是要把PD、TiKV集群同时在本机上建立起来，还是有一点难度的。好在pingcap官方提供了docker-compose搭建集群的方式，可以快速的在个人电脑上启动一个TiDB的集群。但是，我要的不只是一个集群，我还希望在我的mac上实时编译调试TiDB服务，这个TiDB服务能够和docker-compose的集群里的PD和TiKV进行实时的通讯。我今天仔细分析了一下，最终总结出两个问题需要解决： PD和TiKV的端口需要暴露给宿主机； 宿主机上的TiDB服务需要解决docker-compose服务内部域名调用的问题； 解决方案 第一个问题比较容易解决，docker本身就提供了解决方案，就是把docker内部的端口映射给宿主机，这样在宿主机上就可以直接访问这个端口。第二个问题，我还是思考了一会，最后决定使用修改本机host的方式来完成映射。 mac上需要增加的host如下： 127 .0 .0 .1 pd0 127 .0 .0 .1 pd1 127 .0 .0 .1 pd2 127 .0 .0 .1 tikv0 127 .0 .0 .1 tikv1 127 .0 .0 .1 tikv2 大家一看也就明白了

Overview A complete TiDB cluster contains PD, TiKV, and TiDB. To start the database service, follow the order of PD -> TiKV -> TiDB. To stop the database service, follow the order of stopping TiDB -> TiKV -> PD. Before you start, see TiDB architecture and Software and Hardware Requirements . This document describes the binary deployment of three scenarios: To quickly understand and try TiDB, see Single node cluster deployment . To try TiDB out and explore the features, see Multiple nodes cluster deployment for test . To deploy and use TiDB in production, see Multiple nodes cluster deployment .

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 月，跳不动了？>>> 本文转载自公众号 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 月，跳不动了？>>> 在学习了 前面的文章 之后，相信大家已经对 TiKV 使用的 Raft 核心库 raft-rs 有了基本的了解。 raft-rs 实现了 Raft Leader election 和 Log replication 等核心功能，而消息的发送、接收、应用到状态机等操作则需要使用者自行实现，本文将要介绍的就是 TiKV 中这些部分的处理过程。 Raft Ready 在开始正题之前，我们先简单回顾一下 raft-rs 与外部代码的交互接口: Ready。 Ready 结构的 定义 如下： pub struct Ready { /// The current volatile state of a Node. /// SoftState will be nil if there is no update. /// It is not required to consume or store SoftState. ss: Option<SoftState>, /// The current state of a Node to be saved to stable storage BEFORE /// Messages are sent. /// HardState will be equal to empty state if there is no update

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