势高，则围广：TiDB 的架构演进哲学

本文来源 | PingCAP微信公众号
做者 | PingCAP CEO刘奇，本文根据他在第 100 期 Infra Meetup 上的演讲整理，预计阅读时间为 30 分钟，建议先收藏。

你们可能知道我是 PingCAP CEO，可是不知道的是，我也是 PingCAP 的产品经理，应该也是最大的产品经理，是对于产品重大特性具备一票否决权的人。中国有一类产品经理是这样的，别人有的功能咱们通通都要有，别人没有的功能，咱们也通通都要有，因此你们看到传统的国内好多产品就是一个超级巨无霸，功能巨多、巨难用。因此我在 PingCAP 的一个重要职责是排除掉“看起来应该须要但实际上不须要”的那些功能，保证咱们的产品足够的专一、足够聚焦，同时又具备足够的弹性。

01最初的三个基本信念

本次分享题目是《TiDB 的架构演进哲学》，既然讲哲学那确定有故事和教训，不然哲学从哪儿来呢？但从另外的角度来讲，通常你们来说哲学就先得有信念。有一个内容特别扯的美剧叫作《美国众神》，里面核心的一条思路是“你相信什么你就是什么”。其实人类这么多年来，基本上也是朝这条线路在走的，人类对于未知的东西很难作一个很精确的推导，这时信念就变得很是重要了。

图 1 最初的基本信念

实际上，咱们开始作 TiDB 这个产品的时候，第一个信念就是相信云是将来。当年 K8s 还没火，咱们就坚决的拥抱了 K8s。第二是不依赖特定硬件、特定的云厂商，也就是说 TiDB 的设计方向是但愿能够 Run 在全部环境上面，包括公有云私有云等等。第三是能支持多种硬件，你们都知道咱们支持 X8六、AMD6四、ARM 等等，可能你们不清楚的是 MIPS，MIPS 典型表明是龙芯，除此以外，TiDB 将来还能够在 GPU 上跑（TiFlash 的后续工做会支持 GPU）。

02早期用户故事

一、Make it work

有一句话大概是“眼睛里面写满了故事，脸上没有一点沧桑”，其实现实是残酷的，岁月必定会给你沧桑的。咱们早期的时候，也有相对比较难的时候，这时候就有一些故事关于咱们怎么去经历、怎么渡过的。

首先你们作产品以前确定先作用户调研，这是通用的流程，咱们当初也作过这个事，跟用户聊。咱们一般会说：“咱们要作一个分布式数据库，自动弹性伸缩，能解决分库分表的问题，你会用吗？”用户说“那确定啊，如今的分库分表太痛苦了。”这是最初咱们获取需求最普通的方式，也是咱们最容易掉入陷阱的方式，就好像“我有一百万，你要不要？确定要。”“我有一瓶水，喝了以后就健康无比，延年益寿你要不要？确定要。”很容易就获得相似的结论。

因此这个一句话结论的代价是咱们进行了长达两年的开发。在这两年的时间里，咱们肯定了不少的技术方向，好比最初 TiDB 就决定是分层的。很显然一个复杂的系统若是没有分层，基本上没有办法很好的控制规模和复杂度。TiDB 分两层，一层是 SQL 层，一层是 key-value 层，那么到底先从哪个层开始写呢？其实从哪层开始均可以，可是总要有一个前后，如何选择？

这里就涉及到 TiDB 的第一条哲学。咱们作一个产品的时候会不断面临选择，那每次选择的时候核心指导思想是什么？核心思想是能一直指导咱们持续往前去迭代，因此咱们第一条哲学就是：永远站在离用户更近的地方去考虑问题。

为何咱们会定义这样一条哲学？由于离用户越近越能更快的获得用户的反馈，更快的验证你的想法是否是可行的。显然 SQL 层离用户更近，因此咱们选择从 SQL 层写起。其实一直到如今，绝大多数用户用 TiDB 的时候根本感觉不到 KV 层的存在，用户写的都是 SQL，至于底层存储引擎换成了别的，或者底层的 RocksDB 作了不少优化和改进，这些变化对于用户关注的接口来讲是不可见的。

选择从 SQL 层开始写以后，接下来面临的问题就是怎么作测试，怎么去更好的作验证，怎么让整个架构，先可以完整跑起来。

在软件开发领域有一条很是经典的哲学：「Make it work, make it right, make it fast」。我想你们每个学软件开发的人，或者每个学计算机的人可能都听过这样一句话。因此当时咱们就作另一个决定，先在已有的 KV 上面构建出一个原形，用最短的时间让整个系统可以先能 work。

咱们在 2015 年的 9 月份开源了第一个版本，当时是没有存储层的，须要接在 HBase 上。当这个系统能跑起来以后，咱们的第一想法是赶忙找到当初调研时说要用的那些用户，看看他们是什么想法，尽快的去验证咱们的想法是否是可行的。由于不少人作产品思惟属于自嗨型，“我作的东西最厉害，只要一推出去确定一群人蜂拥而至。”抱有这种想法的人太多了，实际上，只有尽快去验证才是惟一的解决之道，避免产品走入误区。

图 2 与调研用户第二次对话

然而当我跟用户讲，你须要先装一个 Hadoop，可能还要装一组 Zookeeper，但用户说：“我只想要一个更强大的 MySQL，可是让我装这一堆东西，你是解决问题仍是引入问题？”

这个问题有什么解决办法呢？一个办法是你去解决用户，能够经过销售或者经过某些关系跟用户聊，显然这是一个不靠谱的思路。做为一个产品型的公司，咱们很快就否了这个想法。用户的本质要求是：你不要给我装一堆的东西，要真正解决个人问题。因此咱们立刻开始启动分布式 KV 的开发工做，完全解决掉这个问题，知足用户的要求。

图 3 开发 TiKV 前的技术考量

开始开发 KV 层时候又会面临不少技术选择，咱们有不少考量（如图 3）。

第一点，咱们认为做为数据库最重要的是正确性。假设这个数据库要用在金融行业，用在银行、保险、证券，和其余一些很是关键的场合的时候，正确性就是无比重要的东西。没有人会用一个不正确的数据库。

第二点是实现简洁、易用。用户对于一个不简洁、不易用的东西是没法接受的，因此咱们当时的一个想法是必定要作得比 HBase 更加易用，代码量也要比 HBase 小，因此时至今天 TiDB 代码量仍然是比 HBase 小得多，大约还不到 HBase 的十分之一。

第三点考虑是扩展性。 TiDB 不只在总体上是分层的，在存储层 TiKV 内部也是分层的，因此有很是好的扩展性，也支持 Raw KV API、Transaction API，这个设计后来也收获了不少用户的支持，好比一点资讯的同窗就是用的 Raw KV API。

第四点就是要求高性能低延迟。你们对于数据库的性能和延迟的追求是没有止境的，可是咱们当时并无把太多精力花在高性能低延迟上。刚才说到咱们有一条哲学是「Make it work, make it right, make it fast」，你们能够看到这句话里面 「Fast」是放最后的，这一点也是 TiDB 和其余产品有很是大的差别的地方。做为一个技术人员，一般你们看一个产品好很差，就会想：“来，不服跑个分，产品架构、易用性、技术文档、Community 这些指标都不看，先跑个分让你们看看行不行”。这个思路真正往市场上去推时是不对的。不少事情的选择是一个综合的过程。你可让你的汽车跑的巨快无比，上面东西全拆了就留一个发动机和四个轮子，那确定也是跑得巨快，重量轻，并且仍是敞篷车，但没有一我的会在路上用的。一样的，选择 Rust 也是综合考量的结果。咱们看中了 Rust 这个很是具备潜力的语言。当时 Rust 没有发布 1.0，还不是一个 stable 版本，但咱们相信它会有 1.0。大概过了几个月，Rust 就发布了 1.0 版本，证实咱们的选择仍是很是正确的。

最后一点就是稳定性。做为一个分布式数据库，每一层的稳定性都很是重要。最底下的一个存储引擎，咱们选择了很是稳定的 RocksDB。不事后来咱们也查到几个 RocksDB 掉数据的 Bug。这也是作数据库或者说作基础产品的残酷性，咱们在作产品的过程当中找到了 Rust 编译器的 Bug，XFS 掉数据的 Bug，RocksDB 掉数据的 Bug，好像几大基础组件的 Bug 都聚在这里开会。

接着咱们辛辛苦苦干了三个月，而后就开源了 TiKV，因此这时候看起来没有那么多的组件了。咱们也不忘初心，又去找了咱们当初那个用户，说咱们作了一些改进，你要不要试一试。

图 4 与调研用户第三次对话

可是用户这时候给了一个让咱们很是伤心很是难受的回答：没有，咱们不敢上线，虽然大家的产品听起来挺好的，可是数据库后面有很大的责任，心理上的担忧确实是过不去。因而咱们回去开始加班加点写 TiDB Binlog，让用户能够把 binlog 同步给 MySQL。毕竟用户须要一个 Backup：万一 TiDB 挂了怎么办，我须要切回 MySQL，这样才放心，由于数据是核心资产。

图 5 第一个上线用户的架构图

因此最终咱们第一个用户上线的时候，整个 TiDB 的架构是这样的（如图 5）。用户经过 Client 连上 TiDB，而后 TiDB 后面就经过 Binlog 同步到 MySQL。后来过了一段时间，用户就把后面的 MySQL 撤了。咱们当时挺好奇为何撤了，用户说，第一个缘由是后面 MySQL 撑不起一个集群给它回吐 Binlog，第二就是用了一段时间以为 TiDB 挺稳定的，而后就不须要 Binlog 备份了。

其实第一个用户上线的时候，数据量并不算大，大概 800G 的数据，使用场景是 OLTP 为主，有少许的复杂分析和运算，但这少许的复杂分析运算是当时他们选择 TiDB 最重要的缘由。由于当时他们须要每隔几分钟算一个图出来，若是是在 MySQL 上面跑，大约须要十几分钟，但他们须要每隔几分钟打一个点，后来忽然发现次日才能把前一天的点都打出来，这对于一个实时的系统来讲就很不现实了。虽然这个应用实践只有少部分运算，但也是偏 OLAP，我记得 TiDB 也不算特别快，大概是十几秒钟，由于支持了一个并行的 Hash Join。

无论怎样，这个时候终于有第一个用户能证实咱们作到了「Make it work」。

二、Make it right

接下来就是「Make it right」。你们可能想象不到作一个保证正确性的数据库这件事情有多么难，这是一个巨大的挑战，也有巨大的工做量，是从理论到实践的距离。

图 6 理论到实践的距离

（1）TLA+ 证实

你们可能会想写程序跟理论有什么关系？其实在分布式数据库领域是有一套方法论的。这个方法论要求先实现正确性，而实现正确的前提是有一个形式化的证实。为了保证整个系统的理论正确，咱们把全部的核心算法都用 TLA+ 写了一遍证实，而且把这个证实开源出去了，若是你们感兴趣能够翻看一下（https://github.com/pingcap/tl...）。之前写程序的时候，你们不多想到先证实一下算法是对的，而后再把算法变成一个程序，其实今天还有不少数据库厂商没有作这件事。

（2）千万级别测试用例

在理论上保证正确性以后，下一步是在现实中测试验证。这时只有一个办法就是用很是庞大的测试用例作测试。你们一般本身作测试的时候，测试用例应该不多能达到十万级的规模，而咱们如今测试用例的规模是以千万为单位的。固然若是以千万为单位的测试用例靠纯手写不太现实，好在咱们兼容了 MySQL 协议，能够直接从 MySQL 的测试用例里收集一些。这样就能很快验证整个系统是否具有正确性。

这些测试用例包括应用、框架、管理工具等等。好比有不少应用程序是依赖 MySQL，那直接拿这个应用程序在 TiDB 上跑一下，就知道 TiDB 跟 MySQL 的兼容没问题，如 Wordpress、无数的 ORM 等等。还有一些 MySQL 的管理工具能够拿来测试，好比 Navicat、PHP admin 等。另外咱们把公司内部在用的 Confluence、Jira 后面接的 MySQL 都换成了 TiDB，虽说规模不大，可是咱们是但愿在应用这块有足够的测试，同时本身「Eat dog food」。

（3）7*24 的错误注入测试用例

这些工做看起来已经挺多的了，但实际上还有一块工做比较消耗精力，叫 7*24 的错误注入测试。最先咱们也不知道这个测试这么花钱，咱们如今测试的集群已是几百台服务器了。若是创业的时候就知道须要这么多服务器测试，咱们可能就不创业了，好像天使轮的融资都不够买服务器的。不过好在这个事是一步一步买起来，刚开始咱们也没有买这么多测试服务器，后来随着规模的扩大，不断的在增长这块的投入。

你们可能到这儿的时候仍是没有一个直观的感觉，说这么多测试用例，究竟是一个什么样的感觉。咱们能够对比看一下行业巨头 Oracle 是怎么干的。

图 7 前 Oracle 员工的描述（https://news.ycombinator.com/...）

这是一篇在 HackNews上面的讨论，讨论的问题是：你以为这个最坏的、规模最大的代码是什么样子的？下面就有一个 Oracle 的前员工就介绍了 Oracle Database 12.2 这个版本的状况。他说这个总体的源代码接近 2500 万行 C 代码，可能你们维护 25 万行 C 代码的时候就会痛不欲生了，能够想一想维护这么多代码的是一种什么样的感觉。到如今为止，TiDB 的代码应该还不到 25 万行。固然 TiDB 的功能远远没有 Oracle 那么多，Oracle 的功能实际上是不少的，历史积累一直往上加，加的很凶。

这位 Oracle 前员工介绍了本身在 Oracle 的开发工做的流程，以下图：

图 8 Oracle 开发者 fix bug 的过程

好比用户报了一个 Bug，而后他开始 fix。第一件事是花两周左右的时间去理解 20 个不一样的 flag，看看有没有可能由于内部乱七八糟的缘由来形成这个 Bug。你们可能不知道 MySQL 有多少变量，我刚作 TiDB 的时候也不知道，当时我以为本身是懂数据库的，后来去看了一下 MySQL 的 flag 的变量数就惊呆了，但看到 Oracle 的 flag 变量数，那不是惊呆了，是绝望了。你们可能知道开启 1 个 flag 的时候会对什么东西有影响，可是要去理解 20 个 flag 开启时和另外几个 flag 组合的时候都有什么影响，可能会崩溃。因此其实精通 Oracle 这件事情，实际上可能比精通 C++ 这件事情更困难的。一个 Oracle 开发者在内部处理这件事情都这么复杂，更况且是外面的用户。但 Oracle 确实是功能很强大。

说回这位前 Oracle 员工的描述，他接着添加了更多的 flag 处理一个新的用户场景的问题，而后增强代码，最后改完之后会提交一个测试。先在 100 到 200 台机器上面把这个 Oracle 给 build 出来，而后再对这个 Oracle 去作新的测试。他应该对 Oracle 的测试用例的实际数量了解不深入，我猜他可能不知道 Oracle 有多少个测试，因此写的是 “millions of tests”，这显然过低估了 Oracle 的测试数量。一般状况下，只会看到挂了的测试，看不到所有的测试数量。

下面的步骤更有意思了：Go home，由于整个测试须要 20-30 个小时，跑完以后测试系统反馈了一个报告：挂了 200 多个 test，更茫然的是这 200 tests 他之前都没见过，这也是 Oracle 很是强大的一个地方，若是一个开发者的代码提交过去挂掉一两百个测试，是很正常的事情，由于 Oracle 的测试能 Cover 东西很是多，是这么多年来很是强大的积累，不停的堆功能的同时就不停的堆测试，固然也不停的堆 flag。因此从另外一个角度来看，限制一个系统的功能数量，对于维护来讲是很是重要的。

总之，看完这个回复以后，我对行业前辈们充满了敬畏之情。

三、Make it fast

（1）新问题

随着 TiDB 有用户开始上线，用户的数量和规模愈来愈大，这时候就出现了一个颇有意思的事情，一部分用户把 TiDB 当成了能够支持事务、拥有良好实时性的数据仓库在用，和咱们说：咱们把公司 Hadoop 换了，数据量十几 T。

咱们就一下开始陷入了深深的思考，由于 TiDB 原本设计的目的不是这个方向，咱们想作一个分布式 OLTP 数据库，并无想说咱们要作一个 Data Warehouse。可是用户的理由让咱们以为也颇有道理，没法反驳——TiDB 兼容 MySQL，会 MySQL 的人不少，更好招人，最重要的是 Hadoop 跑得还不够快。

虽然咱们本身也很吃惊，但这体现了 TiDB 另外一方面的价值，因此咱们继续问用户还有什么痛点。用户表示还有一部分查询不够快，数据没办法作到 shuffle，并且之前用 Spark，TiDB 好像没有 Spark 的支持。

咱们想了想，TiDB 直接连 Spark 也是能够的，但这样 Spark 对底下没有感知，事务跑得巨慢，就跟 Spark 接 MySQL 没什么差异。咱们研究了一下，作出了一个新的东西——TiSpark。TiSpark 就开始可以同时在 TiDB 上去跑 OLAP 和 OLTP。

图 9 出现的新问题

就在咱们准备改进 TiDB 的数据分析能力的时候，忽然又有一大批 TP 用户上线了，给咱们报了一堆问题，好比执行计划不许确，选不到最优执行计划，数据热点分布不均匀，Raft store 单线程写入瓶颈，报表跑的慢等等……因而咱们制定了 1.0 到 2.X 的计划，先把用户提的这些问题一一解决。

这里有另一条哲学：将用户遇到的问题放在第一优先级。咱们从产品最初设计和以后 Roadmap 计划永远是按照这个原则去作的。

首先，执行计划不许确的问题。最简单有效的解决办法是加一个 Index Hint，就像是“你告诉我怎么执行，我就怎么执行，我本身不会自做聪明的选择”。但这不是长久之计，由于用户多是在一个界面上选择各类条件、参数等等，最后拼成一个 SQL，他们本身没办法在里面加 Index Hint。咱们不能决定用户的使用习惯，因此从这时开始，咱们决定从 RBO（Rule Based Optimizer）演进到 CBO（Cost Based Optimizer），这条路也走了很是久，并且还在持续进行。

第二个是热点数据处理问题。咱们推出了一个热点调度器，这个可能你们在分布式数据库领域第一次据说，数据库领域应该是 PingCAP 独创。 热点调度器会统计、监控整个系统热点状况，再把这些热点作一个快速迁移和平衡，好比整个系统有 10 个热点，某一个机器上有 6 个热点，这台机器就会很卡，这时热点调度器会开始将热点打散，快速分散到集群的其余机器上去，从而让整个集群的机器都处于比较正常的负载状态。

第三个就是解决 Raft store 单线程瓶颈的问题。为了改变 Raft store 单线程，咱们大概花了一年多的时间，目前已经在 TiDB 3.0 里实现了。咱们将 Raft store 线程更多耗时的计算变成异步操做，offload 到其它线程。不知道有没有人会好奇为何这个改进会花这么长时间？咱们一直认为数据库的稳定性第一位的。分布式系统里面一致性协议自己也复杂，虽说 Raft 是比 Paxos 要简单，但它实际作起来也很复杂，要在一个复杂系统里支持多线程，而且还要作优化，尽量让这个 I/O 能 group 到一块儿，其实很是耗精力。

第四个就是解决报表跑得慢的问题，这个骨头特别硬，咱们也是啃到今天还在继续。首先要大幅提高 TiDB 在分析场景下的能力。你们均可以看到咱们在发布每个版本的时候，都会给出与上一个版本的 TPC-H 性能对比（TPC-H 是一个有很是多的复杂查询、大量运算的场景）。其次就是高度并行化，充分利用多核，并提供参数控制，这个特性可能不少用户不知道，咱们能够配一下参数，就让 TiDB 有多个并发在底层作 Scan（https://github.com/pingcap/do...）。

解决完这些问题，咱们终于以为能够喘口气了，但喘气的时间就不到一个星期，很快又有不少用户的反馈开始把咱们淹没了。由于随着用户规模的扩大，用户反馈问题的速度也变得愈来愈快，咱们处理的速度不必定跟的上用户的增速。

（2）新呼声

这时候咱们也听到了用户的一些「新呼声」。

有用户说他们在跑复杂查询时 OLTP 的查询延迟变高了，跑一个报表的时候发现 OLTP 开始卡了。这个问题的缘由是在跑复杂查询的时候，SQL 资源被抢占。咱们又想有没有可能将 OLAP 和 OLTP 的 Workload 分开？因而咱们搞了第一个实验版本，在 TiKV 里把请求分优先级，放到不一样队列里面去，复杂 Query 放在第一优先级的队列， OLTP 放在高优先级。而后咱们发现本身是对报表理解不够深入，这个方案只能解决一部分用户的问题，由于有的报表跑起来须要几个小时，致使队列永远是满的，永远抢占着系统的资源。还有一部分用户的报表没有那么复杂，只是但愿报表跑得更快、更加实时，好比一个作餐饮 SaaS 的用户，天天晚上须要看一下餐馆营收状况，统计一家餐馆时速度还行，若是统计全部餐馆的状况，那就另说了。

另外，报表有一些必需品，好比 View 和 Window Function，没有这些的话 SQL 写起来很痛苦，缺少灵活度。

与此同时，用户关于兼容性和新特性的要求也开始变多，好比但愿支持 MySQL 相似的 table partition，还有银行用户习惯用悲观锁，而 TiDB 是乐观锁，迁移过来会形成额外的改形成本（TiDB 3.0 已经支持了悲观锁）。

还有用户有 400T 的数据，没有一个快速导入的工具很是耗时（固然如今咱们有快速导入工具TiDB Lightning），这个问题有一部分缘由在于用户的硬件条件限制，好比说千兆网导入数据。

还有些用户的数据规模愈来愈大，到 100T 以上就开始发现十分钟已经跑不完 GC 了（TiDB 的 GC 是每十分钟一次），一个月下来 GC 已经总体落后了很是多。

图 10 用户的新呼声

咱们当时很是头痛，收到了一堆意见和需求，压力特别大，而后赶忙汇总了一下，如图 10 所示。面对这么多的需求，咱们考虑了两个点：

哪些是共性需求？
什么是完全解决之道？

把共性的需求都列在一块，提供一个在产品层面和技术层面真正的完全的解决办法。

好比图 10 列举的那么多问题，其实真正要解决三个方面：性能、隔离和功能。性能和隔离兼得好像很困难，可是这个架构有很是独特的优点，也是能够作获得的。那能够进一步「三者兼得」，同时解决功能的问题吗？咱们思考了一下，也是有办法的。TiDB 使用的 Raft 协议里有一个 Raft Learner 的角色，能够不断的从 Leader 那边复制数据，咱们把数据同步存成了一个列存，刚才这三方面的问题均可以用一个方案去完全解决了。

首先复杂查询的速度变快了，众所周知分析型的数据引擎基本上所有使用的是列存。第二就是强一致性，整个 Raft 协议能够保证从 Learner 读数据的时候能够选择一致性的读，能够从 Leader 那边拿到 Learner 当前的进度，判断是否能够对外提供请求。第三个是实时性能够保证，由于是经过 streaming 的方式复制的。

因此这些看上去很是复杂的问题用一个方案就能够解决，而且强化了原来的系统。这个「强化」怎么讲？从用户的角度看，他们不会考虑 Query 是 OLAP 仍是 OLTP，只是想跑这条 Query，这很合理。用一套东西解决用户的全部问题，对用户来讲就是「强化」

问题的思考

![图片上传中...]

图 11 成本问题

不少用户都跟咱们反馈了成本问题，用户以为所有部署到 SSD 成本有点高。一开始听到这个反馈，咱们还不能理解，SSD 已经很便宜了呀，并且在整个系统来看，存储机器只是成本的一小部分。后来咱们深入思考了一下，其实用户说得对，不少系统都是有迟早高峰的，若是在几百 T 数据里跑报表，只在天天晚上收工时统计今天营业的情况，那为何要求用户付出最高峰值的配置呢？这个要求是不合理的，合不合理是一回事，至于作不作获得、怎么作到是另一回事。

因而咱们开始面临全新的思考，这个问题本质上是用户的数据只有一部分是热的，可是付出的代价是要让机器 Handle 全部的数据，因此能够把问题转化成：咱们能不能在系统里面作到冷热数据分离？能不能支持系统动态弹性的伸缩，伸展热点数据，用完就释放？

若是对一个系统来讲，峰值时段和非峰值时段的差异在于峰值时段多了 5% 的热点。咱们有必要去 Handle 全部的数据吗？因此完全的解决办法是对系统进行合理的监控，检测出热点后，立刻建立一个新的节点，这个新的节点只负责处理热点数据，而不是把全部的数据作动态的 rebalance，从新搬迁。在峰值时间过去以后就能够把复制出来的热点数据撤掉，占的这个机器能够直接停掉了，不须要长时间配备很是高配置的资源，而是动态弹性伸缩的。

TiDB 做为一个高度动态的系统，自己的架构就具备很是强的张力，像海绵同样，可以知足这个要求，并且能根据系统负载动态的作这件事。这跟传统数据库的架构有很大的区别。好比有一个 4T 的 MySQL 数据库，一主一从，若是主库很热，只能立刻搞一个等配的机器重挂上去，而后复制所有数据，但实际上用户须要的只是 5% 的热数据。而在 TiDB 里，数据被切成 64MB 一个块，能够很精确的检测热数据，很方便的为热数据作伸展。这个特性预计在 TiDB 4.0 提供。

这也是一个良好的架构自己带来的强大的价值，再加上基于 K8s 和云的弹性架构，就能够获得很是多的不同的东西。一样的思路，若是我要作数据分析，必定是扫所有数据吗？对于一个多租户的系统，我想统计某个餐馆今天的收入，数据库里有成千上万个餐馆，我须要运算的数据只是其中一小块。若是我要快速作列存计算时，须要把数据所有复制一份吗？也不须要，只复制我须要的这部分数据就行。这些事情只有一个具备弹性、高度张力的系统才能作到。这是 TiDB 相对于传统架构有很是不同的地方。时至今天，咱们才算是把整个系统的架构基本上稳定了，基于这个稳定的架构，咱们还能够作更多很是具备张力的事情。

因此，用一句话总结咱们解决成本问题的思路是：必定要解决真正的核心的问题，解决最本质的问题。

04关于横向和纵向发展的哲学

TiDB 还有一条哲学是关于横向和纵向发展的选择。

一般业内会给创业公司的最佳建议是优先打“透”一个行业，由于行业内复制成本是最低的，可复制性也是最好的。但 TiDB 从第一天开始就选择了相反的一条路——「先往通用性发展」，这是一条很是艰难的路，意味着放弃了短期的复制性，但其实咱们换取的是更长时间的复制性，也就是通用性。

由于产品的总体价值取决于总的市场空间，产品的普遍程度会决定产品最终的价值。早期坚决不移的往通用性上面走，有利于尽早感知整个系统是否有结构性缺陷，验证本身对用户需求的理解是否具备足够的广度。若是只往一个行业去走，就没法知道这个产品在其余行业的适应性和通用性。若是咱们变成了某个行业专用数据库，那么再往其余行业去发展时，面临的第一个问题是本身的恐惧。这恐惧怎么讲呢？Database 应该是一个通用型的东西，若是在一个行业里固定了，那么你要如何肯定它在其余场景和行业是否具备适应性？

这个选择也意味着咱们会面临很是大的挑战，一上来先作最厉害的、最有挑战的用户。若是你们去关注整个 TiDB 发展的用户案例的状况，你会注意到 TiDB 有这样一个特色，TiDB 是先作百亿美金以上的互联网公司，这是一个很是难的选择。但你们应该知道，百亿美金以上的互联网公司，在选择一个数据库等技术产品的时候，是没有任何商业上的考量的，对这些公司来讲，你的实力是第一位的，必定要能解决他们问题，才会承认你整个系统。但这个也很差作，由于这些公司的应用场景一般都压力巨大。数据量巨大，QPS 特别高，对稳定性的要求也很是高。咱们先作了百亿美金的公司以后，去年咱们有 80% 百亿美金以上的公司用 TiDB，除了把咱们当成竞争对手的公司没有用，其余所有在用。而后再作 30 亿美金以上的公司，今年是 10 亿美金以上的用户，实际上如今是什么样规模的用户都有，甭管多少亿美金的，“反正这东西挺好用的，我就用了。”因此咱们如今也有人专门负责在用户群里面回答你们的提问。

其实当初这么定那个目标主要是考虑数据量，由于 TiDB 做为一个分布式系统必定是要处理具备足够数据量的用户场景，百亿美金以上的公司确定有足够的数据，30 亿美金的公司也会有，由于他们的数据在高速增加，当咱们完成了这些，而后再开始切入到传统行业，由于在这以前咱们通过了稳定性的验证，

景的验证。

![图片上传中...]

图 12 横向发展与纵向发展

坚持全球化的技术视野也是一个以横向优先的发展哲学。最厉害的产品必定是全球在用的。这个事情的最大差别在于视野和格局，而格局最终会反映到人才上，最终竞争不是在 PingCAP 这两百个员工，也不是如今 400 多个 Contributors，将来可能会有上千人参与整个系统的进化迭代，在不一样的场景下对系统进行打磨，因此竞争本质上是人才和场景的竞争。基于这一条哲学，因此才有了如今 TiDB 在新一代分布式数据库领域的全面领先，不管是从 GitHub Star 数、 Contributor 数量来看，仍是从用户数据的规模、用户分布的行业来看，都是领先的。一样是在作一个数据库，你们的指导哲学不同会致使产品最终的表现和收获不同，迭代过程也会彻底不同。咱们在作的方向是「携全球的人才和全球的场景去竞争」。

关于横向和纵向发展，并非咱们只取了横向。

2019 年 TiDB 演进的指导思想是：稳定性排第一，易用性排第二，性能第三，新功能第四。这是我在 2018 年通过思考后，把咱们发展的优先级作了排序。上半年咱们重点关注的是前两个，稳定性和易用性。下半年会关注纵向发展，「Make it fast」实际上是纵向上精耕细做、释放潜力的事情。这个指导思想看起来好像又跟其余厂商想法不太同样。

咱们前面讲的三条哲学里面，最后一条就是「Make it fast」，若是要修建五百层的摩天大楼，要作的不是搭完一层、装修一层，立刻给第一层作营业，再去搭第二层。而必定要先把五百层的架构搭好，而后想装修哪一层均可以。TiDB 就是「摩天大楼先搭架构后装修」的思路，因此在 TiDB 3.0 发布以后，咱们开始有足够的时间去作「装修」的事情。

05总结与展望

说了这么多故事，若是要我总结一下 2015 - 2019 年外面的朋友对 TiDB 的感觉，是下图这样的：

图 13 2015-2019 小结

2015 年，当咱们开始作 TiDB 的时候，你们说：啊？这事儿大家也敢干？由于写一个数据库自己很是难，写一个分布式数据库就是无比的难，而后仍是国人自主研发。到 2016 年的时候，你们以为你好像折腾了点东西，听到点声音，但也没啥。到 201七、2018 年，你们看到有愈来愈多用户在用。2019 年，能看到更多使用后点赞的朋友了。

我昨天翻了一下 2015 年 4 月 19 日发的一条微博。

图 14 刚创业时发的微博

当时咱们正准备创业，意气风发发了一条这样微博。这一堆话其实不重要，你们看一下阅读量 47.3 万，有 101 条转发，44 条评论，然而我一封简历都没收到。当时你们看到咱们都以为，这事儿外国人都没搞，你行吗？折腾到今天，我想应该没有人再对这个问题有任何的怀疑。不少国人其实能力很强了，自信也能够同步跟上来，毕竟咱们拥有全球最快的数据增速，不少厂家拥有最大的数据量，对产品有最佳的打磨场景。

想一想当时我也挺绝望的，想着应该还有很多人血气方刚，还有不少技术人员是有很是强大的理想的，可是前面我也说了，总有一个从理想到现实的距离，这个距离很长，好在如今咱们能收到不少简历。因此不少时候你们也很难想象咱们刚开始作这件事情的时候有多么的困难，以及中间的每个坚持。只要稍微有一丁点的松懈，就可能走了另一条更容易走的路，可是那条更容易走的路，从长远上看是一条更出路的路。

图 15 对 2020 年的展望

最后再说一下 2020 年。在拥有行业复制能力的以后，在产品层面咱们要开始向着更高的性能、更低的延迟、更多 Cloud 支持（无论是公有云仍是私有云均可以很好的使用 TiDB）等方向纵向发展。同时也会支持我刚刚说的，热点根据 Workload 自动伸缩，用极小的成本去扛，仅仅须要处理部分热点的数据，而不是复制整个数据的传统主-从思路。

你们去想想，若是整个系统会根据 Workload 自动伸缩，本质上是一个 self-driving 的事情。如今有愈来愈多的用户把 TiDB 当成一个数据中台来用，有了 TiDB 行列混存，而且 TiDB 对用户有足够透明度，就至关因而握有了 database 加上 ETL，加上 data warehouse，而且是保证了一致性、实时性的。

昨天我写完 slides 以后想起了之前看的一个电视剧《大秦帝国》。第一部第九集里有一段关于围棋的对话。商鞅执黑子先行，先下在了一个应该是叫天元位置，大约在棋盘的中间。你们知道通常下围棋的时候都是先从角落开始落子居多。商鞅的对手就说，我许你重下，意思就是你不要开玩笑，谁下这儿啊？因而商鞅说这样一句话，“中枢之地，辐射四极，雄视八荒”，这也是一个视野和格局的事情。而后对手说：“先生招招高位，步步悬空，全无根基实地”，就是看起来好像是都还挺厉害的，一点实际的基础都没有，商鞅说：“旦有高位，岂无实地？”，后来商鞅赢了这盘棋，他解释道：“棋道以围地为归宿，但必以取势为根本。势高，则围广”。

这跟咱们作 TiDB 其实很像，咱们一上来就是先作最难最有挑战的具备最高 QPS 和 TPS、最大数据量的场景，这就是一个「取势」的思路，由于「势高，则围广」。因此咱们更多时候是像我前面说的那样，站在哲学层面思考整个公司的运转和 TiDB 这个产品的演进的思路。这些思路不少时候是你们看不见的，由于不是一个纯粹的技术层面或者算法层面的事情。

以上内容来自PingCAP CEO刘奇的分享。

活动推荐

2019年6月21-23日，GIAC全球互联网架构大会将在深圳举办，组委会从互联网架构最热门的Cloud-Native、IoT、人工智能等前沿技术、数据及商业智能、大中台、经典架构、工程文化及管理等领域甄选前沿的有典型表明的技术创新及研发实践的架构案例，邀请了BAT、美团、滴滴等企业技术专家为咱们分享最新的技术成果，识别图中二维码便可有机会得到大会体验票一张！