TiDB

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

作者介绍：我和我的 SQL 队（成员：杜沁园、韩玉博、黄宝灵、满俊朋），他们的项目「基于路径统计的 sql bug root cause 分析」获得了 TiDB Hackathon 2019 的三等奖。 曾在 Hacker News 上看到过一个 Oracle 工程师处理 bug 的 日常 ： 先花两周左右时间来理解 20 个参数如何通过神奇的组合引发 bug。 改了几行代码，尝试对 bug 进行修复，提交测试集群开始跑近百万个测试 case，通常要 20~30 小时。 运气好的话会有 100 多个 case 没过，有时候上千个也有可能，只好挑选几个来看，发现还有 10 个参数之前没有注意到。 又过了两周，终于找到了引起 bug 的真正参数组合，并跑通了所有测试。并增加 100 多个测试 case 确保覆盖他的修改。 经过一个多月的代码 review，他的修改终于合并了，开始处理下一个 bug…… 后来这个工程师感慨说：“I don't work for Oracle anymore. Will never work for Oracle again!” Oracle 12.2 有将近 2500 万行 C 代码，复杂系统的测试是一件艰难、艰苦和艰巨的事情。而测试一个分布式数据库的情况就更复杂了，我们永远不知道用户可能写出什么样的 SQL，表结构和索引有多少种组合

作者介绍：我和我的 SQL 队（成员：杜沁园、韩玉博、黄宝灵、满俊朋），他们的项目「基于路径统计的 sql bug root cause 分析」获得了 TiDB Hackathon 2019 的三等奖。 曾在 Hacker News 上看到过一个 Oracle 工程师处理 bug 的 日常 ： 先花两周左右时间来理解 20 个参数如何通过神奇的组合引发 bug。 改了几行代码，尝试对 bug 进行修复，提交测试集群开始跑近百万个测试 case，通常要 20~30 小时。 运气好的话会有 100 多个 case 没过，有时候上千个也有可能，只好挑选几个来看，发现还有 10 个参数之前没有注意到。 又过了两周，终于找到了引起 bug 的真正参数组合，并跑通了所有测试。并增加 100 多个测试 case 确保覆盖他的修改。 经过一个多月的代码 review，他的修改终于合并了，开始处理下一个 bug…… 后来这个工程师感慨说：“I don't work for Oracle anymore. Will never work for Oracle again!” Oracle 12.2 有将近 2500 万行 C 代码，复杂系统的测试是一件艰难、艰苦和艰巨的事情。而测试一个分布式数据库的情况就更复杂了，我们永远不知道用户可能写出什么样的 SQL，表结构和索引有多少种组合

作者：MingCong Han 在《 十分钟成为 Contributor 系列 | 为 Cascades Planner 添加优化规则 》中，我们简单介绍了 Cascades 的相关背景知识，本文将为大家深入介绍 TiDB 新的优化器——Cascades Planner 的框架及原理。 TiDB 当前优化器简介 关系型数据库中查询优化器的作用是为一个 SQL 在合理的开销内产生一个合适的查询计划， TiDB 源码阅读系列文章（六）Select 语句概览 中介绍过 TiDB 当前优化器的基本组成，TiDB 当前的优化器将优化过程主要分为逻辑优化（Logical Optimize）和物理优化（Physical Optimize）两个阶段。逻辑优化是将一棵逻辑算子树（LogicalPlan Tree）进行逻辑等价的变化，最后的结果是一棵更优的逻辑算子树；而物理优化则是将一棵逻辑算子树转换成一棵物理算子树（PhysicalPlan Tree）。这棵物理算子树就是我们说的物理执行计划，将交由 TiDB 执行引擎去完成后续的 SQL 执行过程。 逻辑优化 TiDB 中，一个 SQL 在进入到逻辑优化阶段之前，它的 AST（抽象语法树）已经转换成了对应的逻辑算子树，因此逻辑优化就是将一个逻辑算子树进行逻辑上等价变换的过程。逻辑优化是基于规则的优化（Rule-Based Optimization

一、项目介绍 汽车之家社区于 2005 年上线，作为之家最老的业务之一，十四年来沉淀了亿级帖子、十亿级回复数据，目前每天有千万级 DAU、亿级的访问量，接口日均调用量 10亿+次 。期间经历过架构升级重构、技术栈升级等，但其数据始终存放在SQL Server中，随着数据的不断递增，我们在使用SQL Server 数据库方面遇到了很多瓶颈，以至于我们不得不寻找一个新的数据库替换方案。 二、使用SQL Server遇到的瓶颈 随着业务的不断扩大，汽车之家社区的访问量和发表量不断上涨，遇到的数据库问题也越来越多，下面列举两个必须很快要解决掉的问题： 历史上，之家社区回复库采用了分库分表的设计，用以解决SQL Server单表过大的时候性能下降等问题。时至今日，回复库有100+个库、1000+张表（根据帖子ID分库分表）。这本身并没有问题，代码写好了，数据该写哪里写哪里，该读哪里读哪里。但是随着应用的发展、需求的变化，我们发现在实现某些需求时，分库分表的结构难以满足。我们需要数据逻辑上在一张表里。 近些年来，随着业务加速成长，数据量突飞猛进，而硬盘容量是有限的，每台服务器上能扩展的硬盘数量也是有限的。致使每隔一段时间都要增加更大容量的存储服务器来应对，而且这个事情一开始是很复杂的，涉及到很多关联项目，即便到现在我们轻车熟路了，每次换服务器的时候依然需要关注它，并且大容量数据库服务器价格昂贵

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

1.下载压缩包 安装tar包路径 命令：wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz 命令：wget http://download.pingcap.org/tidb-latest-linux-amd64.sha256 2.检查文件完整性 命令：sha256sum -c tidb-latest-linux-amd64.sha256 tidb-latest-linux-amd64.tar.gz: OK #返回ok说明文件没问题 3.解压 命令：tar -xzf tidb-latest-linux-amd64.tar.gz 命令：cd tidb-latest-linux-amd64/ 4.启动PD 命令：./bin/pd-server --data-dir=/data/pd --log-file=/data/logs/pd.log & #放入后台启动 命令：ps -ef|grep pd-server #查看进程 5.启动TiKV 命令：./bin/tikv-server --pd="127.0.0.1:2379" --data-dir=/data/tikv --log-file=/data/logs/tikv.log & #放入后台启动 命令：ps -ef|grep tikv-server #查看进程 6

业务同学遇见这样的一个问题 select * from t where id>100 order by id asc limit 200; 发现只查到了10个数据 最小的id是101，最大的id是130 然后去控制台执行 select * from t where id>100 and id<=130; 发现又能获取到30个数据 推测是TIDB自增ID有问题，先写入了ID大的值，后写入了ID小的值 查到在TIDB官方文档上有解释 https://pingcap.com/docs-cn/stable/faq/tidb/ 1.1.22 TiDB 中，为什么出现后插入数据的自增 ID 反而小？ TiDB 的自增 ID ( AUTO_INCREMENT ) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 AUTO_INCREMENT 的字段。详情可参考 CREATE TABLE 语法 。 来源： https://my.oschina.net/u/4193646/blog/3132278

Markdown：写技术文档、个人博客和读书笔记都很好用的轻量级标记语言 一、Markdown 是什么? Markdown 是一种轻量级标记语言，这个语言的目的是希望大家使用“易于阅读、易于撰写的纯文字格式，并选择性的转换成有效的 XHTML（或是 HTML）”。 Markdown 既可以用来写产品的中英文技术文档、使用说明，也可以用来写个人博客。许多网站都使用 Markdown 或是其变种，例如 GitHub、reddit、简书。 二、Markdown 常用语法 Markdown 的语法超级简单，两分钟了解一下就可上手。这里举几个例子告诉你有多简单： 1. 标题 通过输入特定数量的井号 "#" 即可实现不同级别的标题： # 一级标题 ## 二级标题 ### 三级标题 #### 四级标题 一级标题 二级标题 三级标题 四级标题 2. 列表 Markdown 支持有序列表和无序列表。 无序列表使用星号、加号或是减号均可实现。例如： * PingCAP * TiDB * TiKV PingCAP TiDB TiKV 效果等同于： + PingCAP + TiDB + TiDB 还等同于： - PingCAP - TiDB - TiKV 有序列表使用数字接一个英文句点即可实现。例如： \1. PingCAP \2. TiDB \3. Database 显示效果如下： PingCAP

作者：李仲舒 HAProxy 是一个使用 C 语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter 和 Tuenti 在内的知名网站，及亚马逊网络服务系统都在使用 HAProxy。 TiDB Server 作为无限水平扩展的无状态计算节点，需要能提供稳定且高性能的负载均衡组件用对外统一的接口地址来提供服务，而 HAProxy 在负载均衡的生态中占有很大的市场，TiDB 用户可以将这一成熟稳定的开源工具应用在自己的线上业务中，承担负载均衡、高可用的功能。 HAProxy 简介 HAProxy 由 Linux 内核的核心贡献者 Willy Tarreau 于 2000 年编写，他现在仍然负责该项目的维护，并在开源社区免费提供版本迭代。最新的稳定版本 2.0.0 于 2019 年 8 月 16 日发布，带来更多 优秀的特性 。 HAProxy 部分核心功能 高可用性 ：HAProxy 提供优雅关闭服务和无缝切换的高可用功能； 负载均衡 ：L4（TCP）和 L7（HTTP）负载均衡模式，至少 9 类均衡算法，比如 roundrobin，leastconn，random 等； 健康检查 ：对 HAProxy 配置的 HTTP 或者