现状
小米从创立到今天已经过去了10年，2020年8月16日雷总在线上直播，宣布小米正式开启新十年的创业者计划。第二个月，云平台部门的数据库与存储团队启动了TiDB项目，作为团队在小米新十年中的第一个三年规划。2021年1月，TiDB产品正式在小米的内部私有云上线，落地各项业务。
先介绍一下小米与TiDB的现状。经过近一年的发展，TiDB在小米已经部署了20多个集群，TiKV节点也达到了三位数，覆盖的业务场景包括电商、供应链、大数据等等。右边这个米字logo的词云是由我们的一部分业务线组成的，包括了零售中台、小米有品、智能制造、代工厂、还有门店等。
小米经过十年的发展，在传统数据库上的使用中，确实遇到了相当多的痛点。因为时间有限，这只列举其中四个。
第一，容量瓶颈。我们内部的单机只有2.6 T，经过十年的发展，很多业务线单机的存储都已经达到了2 T以上，甚至只有几百G的空间剩余，马上就要满了。为了解决容量问题，之前一般采用传统的分库分表解决方案，如果你对业务逻辑没有很深的了解，是成本非常高的事情，然而业务线的建设时间往往已经过去很久，以至于代码都不知道从何下手去重构。通过引入TiDB就能够比较轻松地解决这个问题。
第二，高可用。MySQL的主从架构下，我们尝试使用很多方法来做高可用实现，比如通过LB + Orchestrator +中间件的方案来解决。但是，如果半夜主库挂了，可能仍然睡不好觉。
第三，高写入。TiDB作为一个分布式数据库，很好地解决了多点写入的问题。传统的MySQL主从架构，只能写到主库上，很容易达到瓶颈，达到瓶颈之后就会带来非常强的主从延迟。主从延迟就会带来一致性问题，一致性问题对很多业务来说是一个灾难。
最后，我们还有一些历史包袱。小米十年发展以来，我们内部有各种各样的解决方案去适应业务规模的增长,但都各有优劣。小米曾开源过一个叫Gaea的中间件，也是支持分库分表的，我们内部还有其他的中间件，方案非常多，而且都分散在各个业务线。一旦相关人员有一些变动，就会变得非常难以维护。但是TiDB实现了这些方案的打包，我不再需要考虑是用这个中间件还是那个中间件，他们分别适应什么样的场景。
发展
我们发展的非常快，从我们刚刚了解TiDB，到去年9月份接入了第一个业务，然后我们开始正式立项，建立团队。在今年1月份，我们就完成了包括部署、监控、告警、工单等基础能力的建设，开始类似于一个DBaaS平台，去对业务提供服务。
到今年4月，我们开始做质量提升工程，完成了小时级的备份恢复，还有巡检系统、两地三中心等方案的落地，大大提升了业务质量。到今年7月份，业务规模开始快速增长，TiKV节点很快就过百了。我们现在看到的节点数过百，完成业务规模翻倍，其实仅仅就两三个月的时间。因为很多业务确实看到了TiDB很大的一个可扩展性，在遇到存储瓶颈时，他们也很愿意去做这个迁移接入。后面，我们也会持续的去做TiDB、TiKV的稳定性、性能还有成本等方面的工作，并且会重仓云原生的方向。
我们正式成立TiDB团队投入到TiDB产品的落地中还不到一年，和很多厂商相比算是后辈，我们也充分利用了后发优势，直接引入了大量生态产品如BR、TiCDC、TiUP、DM等等这些生态产品极大地减小了我们的运维成本，方便我们构建TiDB服务平台，促进了产品的快速发展。
挑战
其实接入TiDB也不是那么一帆风顺。
第一是从分库分表到TiDB的迁移过程。历史问题造成的上游数据质量堪忧（如业务自行分库分表的设计，主键ID重复，甚至触发器、存储过程等），需要业务端做改造，从而导致迁移周期漫长。
第二是复杂的业务SQL导致查询计划不准。我们的老业务迁到TiDB之后，某一个SQL突然比以前执行时间大大增长。SPM无法完全解决，一是SQL变化多、数量大。二是根据cost，执行计划也会变化。而很多老业务的复杂SQL非常多，我们需要一一去调整查询计划，去帮业务做调优。
第三是部分内部工具对接，比如为了对接内部消息队列，我们建了一个TiCDC的内部分支版本、Drainer的内部分支版本，当然后续比较根源的解决办法是内部工具去迎合外部开源工具，支持相应开源工具的接口。
最后，硬件、软件多方面的性能调教。比如一些反直觉的情况：我们之前使用的一款NVMe硬盘表面上磁盘性能比SSD要高，但实测sysbench的workload和业务的workload都有不小性能差距，有的情况下甚至NVMe的并发性能比SSD还要差一倍。硬件的适配和兼容也是后期我们调优的一个方向。
点赞
第一个是社区支持非常友好，文档非常完善，因此我们的接入非常快速。我之前也讲了，其实仅仅一个季度的时间，我们就把整个以前看来各种高大上的平台做好，可以对业务提供服务了。
第二个是完善的数据库周边生态，降低了运维的成本。我们知道一个数据库产品的落地需要有自动化部署、监控告警、运维管理平台等一系列基建，得益于TiDB社区良好的可观测性和丰富的生态组件如TiUP / BR / Dashboard等等，我们很轻松的完成了相关建设，极大降低了运维成本，减轻了运维压力。
第三个，跨机房，多机房容灾，异地多活这个话题也是一个很深的话题。我们真正实践起来发现TiDB在跨机房上表现得非常优秀，很容易落地三中心的计划。对于一些需要异地容灾的业务来说，TiDB是一个很好的选择。
第四个，加密存储及传输的功能。透明数据加密(Transparent Data Encryption)，简称TDE，是TiDB推出的一个新特性，应用在风控隐私集群上，极大简化了业务逻辑。
最后是说下HTAP的内容。我们内部也有一些HTAP的实践，右边这个指标是我们的一个核心业务做的HTAP的实践，我们之前通过TiSpark打在TiKV上的任务时间是在左边，我们换了TiFlash之后，我们可以看到，无论是从任务执行时间，还是P99延时、负载上，我们都提高了不只三倍。如果我们自己去优化这三倍的性能，需要投入的精力有多少，大家做过性能优化的应该都知道。TiFlash的引入大大简化了我们的工作。
连接
前面我们提到，TiDB丰富的生态，极大降低了我们的运维成本。取之社区，回馈社区。包括TiDB产品在内，很多生态产品我们都有提patch。现在，小米团队是多个产品的contributor，包括dumpling、br、ticdc、tiup等，TiDB产品目前是active contributor。
画虚线的产品TiKV、TiDB Operator，虽然目前还不是contributor，但是我们和PingCAP已经达成合作，后续将持续贡献TiDB、TiKV、TiDB Operator产品，同时也是符合我们持续性优化稳定性、性能及成本目标。
我们不仅仅是DBA，还是研发工程师，都有代码层面了解产品的执拗，当然对生态产品的代码了解也有助于我们落地到业务中，同时反哺社区，帮助完善生态，也是开源社区所倡导的良性循环。
探索
玩过云的，大家可能都知道，云发展历程中经历过很多基础设施的不同潮流，包括选择私有云还是公有云，以及底层的一些框架如何使用。
因为小米的国际化业务现在越来越发达，我们对海外的公有云的需求也会越来越大。所以我们制订了一个全球混合多云的战略。我们同时使用IDC机房和多种公有云，并且对外封装，把他变成一个屏蔽细节的、全球化的混合多云。
这个混合多云的具体有哪些好处呢？
首先是安全性。在国际化业务中，我们可以根据需求把数据存储在不同的位置。这个是可以通过我们的存储来做，业务无需关心。第二个灵活性。我们可以对业务屏蔽掉底层这个复杂的多云环境，从而提供一个通用的环境。这样我们在切换供应商，或者是做一些底层操作的时候，业务就不会有感知。第三个成本。云原生的好处之一，就是优化调度，资源共享。第四个质量。云的另一个好处就是高弹，我们可以快速完成扩缩容。而我们如何在混合云下做高弹，又是一个非常大的挑战。
我这里画了一个非常粗粒度的规划。
用户层我们不展开讲。服务是我们给用户提供的服务，包括运维管控、用户平台、数据流以及一些调优服务。然后是管理：由于TiDB Operator部署在单个K8s集群中，控制范围仅能在单个K8s集群，而我们的需求可能包含跨机房，跨云，甚至IDC和K8s混合（比如TiCDC部署在云中，而TiDB集群在IDC物理机上），所以我们需要在TiDB Operator上另外增加一些自定义调度。所以我们可以看到除了TiDB Operator、传统的CMDB，我们增加了一个自定义的Operator。
底层的资源刚刚已经介绍了大部分，需要提的一项是底层的存储资源。从本地磁盘到云盘到Ceph，再到其他分布式存储。开发者嘉年华的吐槽大会环节，美团的黄潇老师对TiDB对演进方向有一个灵魂拷问：我们未来TiKV到底是继续提高调度呢，还是说去往PolarDB这边靠，做一些共享存储的方案？东旭的回答是：我们为什么不都做呢？
其实我们也在研究这个问题。在支持本地磁盘和云盘的过程中，我们也在调研云原生的分布存储。StarFS是我们数据库与存储团队目前正在自研的分布式云原生文件系统，与普通分布式存储如HDFS、Ceph等有区别，主打高性能、低延迟。分布式存储有一个天然弱势就是latency不稳定，所以很难作为线上数据库的存储后端，目前没有能满足数据库需求的开源分布式存储。StarFS计划采用基于高性能存储介质SSD、NVMe，采用SPDK、RDMA等技术实现适合数据库的分布式存储后端。
当然，这只是初步规划，并在有条不紊推进过程中，也期待引进越来越多的新技术，来迭代优化混合云的架构设计。
云原生探索踩过一些小坑，这里技术细节比较多了。可以简单介绍一下，假如PD-pod假死，Operator的控制逻辑就会失效。表面上是在Running的状态，但其实这个pod已经无法提供服务了，这个坑也很难受。还有一些分布式存储的调度问题、故障切换问题造成服务不可用的问题等。另外Controller的串行化设计也需要注意。我们知道Controller是把你的集群控制在一个期望的状态，但是这个串行化的控制逻辑会让你在扩容TiDB的时候，假如TiDB扩容不成功，TiKV也无法扩容成功，这样的话就导致阻塞，导致你整个运维操作的失败。
预见
最后表达一下期望，我们已经和TiDB社区建立了深度的合作，我们会共同推进混合多云战略，推进核心业务的MySQL迁移，以及做一些Committer的培养。在内部也会继续推进TiDB落地到小米金融、小米AI、小米IoT等多个业务场景。
