作者介绍：许超，VIPKID资深DBA工程师。
本文主要分享TiDB4.0版本在VIPKID的一个应用实践。主要涉及两个部分，第一部分是现在TiDB在VIPKID的一些应用场景，第二部分是介绍一下TiDB4.0给我们带来哪些惊喜和收益。
TiDB在VIPKID的应用场景
首先简单介绍一下VIPKID，VIPKID是一家在线少儿英语教育公司，专注于服务4-15岁的青少儿和他们家长们，主要提供北美外教一对一授课服务，目前已经有超过70万的付费用户。
场景一：大数据量及高并发写入
回归主题，TiDB在VIPKID的第一个应用场景是一些大数据量和高并发写入的场景，如下图所示：
举其中一个例子，我们现在有一套教室排障的系统，这套系统会实时收集教室内的一些事件信息，比如进出教室还有教室内服务初始化的信息，这些信息是通过家长端还有教师端统一上报的，业务同学可以根据这些信息快速定位到教室内的故障，并且做一些排障手段，比如说切换线路之类的来保证一些上课质量。
这套系统目前TPS峰值在1万左右，每天的新增数据量大概有万，这张表只保留最近两个月的数据，目前单表有12亿左右，数据量其实相对来说已经比较大了，这种数据量如果现在放在MySQL里维护成本比较高，所以我们把这套系统的数据整个迁移到TiDB。
在迁移过程我们做了一些小的变动，在原有表的基础上把原来的自增ID去掉了，在建表的时候通过指定配置做一下预先打散，避免高写入量的时候出现写热点问题。关于热点定位，其实TiDB本身之前就提供了很多方式了，比如3.0版本其实通information_schema.TIDB_HOT_REGIONS这张表就可以定位，或者直接可以在PD里获取相应的热点Region信息，但是通过这种方式拿到的其实只是一个RegionID，还需要调用具体的TiDBserver的API来获取定位到具体的表或者索引。在4.0里，TiDBDashboard让热点直观地呈现在我们面前，我们可以直接看到热点写入量、读取量等等热点信息。
场景二：核心模块分库分表后的多维度查询
第二个场景是现在我们的很多核心业务在早期就已经做了分库分表，比如约课表。对分库分表比较了解的同学其实知道，一般分库分表的情况下只会以一个业务列作为ShardingKey做拆分，但是约课表这种情况下可能涉及到的维度比较多，既有教室、老师、学生还有课程；另外可能其他端也会访问这部分数据，比如教师端来访问这部分数据的时候他可能会以教师的维度来访问，如果做拆分的时候是以学生的维度拆分的，那么教师的访问请求会广播到所有分片上，这在线上是并不允许的。针对这个问题，我们最开始有两种解决方案，一种是我们把所有的数据汇聚完放在ES，还有一种方式是业务双写，写两套集群，两套集群以各自的维度拆分。无论哪种方案，不论是对RD来说还是对我们DBA来说维护成本都比较高。
所以我们就借助DM，通过DM将上游所有分片的表实时同步到下游，并且合并成一张全局表，所有的跨维度的查询，无论是管理端运营平台，还是业务指标监控的系统都走TiDB这套系统，查这张全局表，如下图所示：
再简单介绍一下DM分库分表的逻辑，其实逻辑相对比较简单，DM其实会拉取线上所有分片的Binlog日志，然后根据黑白名单过滤匹配出需要同步的那部分binlogevent，再去匹配制定的路由规则，通过改写然后应用到下游的全局表里，这里也区分两种情况：一种情况是上游的分库分表包含全局ID，这种情况其实天然的避免了合并之后的主键冲突的问题。还有一种是没有全局ID的情况，这种情况之前官方提供了一个解决方案是通过Columnmapping的方式，其实就相当于对ID列在同步之前做一些预处理，处理之后相当于在底层同步的时候就不会有主键冲突的问题了。但是我们和PingCAP同学沟通了一下，其实他们现在已经不建议用这种方式了。所以我们换了另外一种方式，因为我们的业务对于这种自增ID、主键ID是没有业务依赖的，所以在下游TiDB这块我其实提前建了下图所示的这样一张表，然后把对应ID的主键属性和自增属性去掉，并且将这个ID加入我原先仅有的一个联合的唯一索引里就解决这个问题了：
在DM这块我们简单地做了两件事。第一是DM的延迟监控，其实DM本身支持延迟监控，也是通过写心跳的方式去做的，但在我们线上把DM并不是挂在MySQL集群的主节点下，而是挂在一个只读存库上，所以我们不太允许DM直接去写存库的心跳。我们线上有一套心跳机制来监控延迟，所以在实际DM这块延迟监控实际复用的是线上的那套心跳表，相当于把线上的那套心跳直接同步下来，也是通过路由规则匹配一下，然后改写。这样的话虽然在TiDB里可能涉及到多个集群，但其实每个集群对应单独的一个心跳表，这样就可以做DM的延迟监控。在下图里大家可以看到，大部分情况下分库分表合并的场景同步延迟基本都在毫秒以内：
第二件事就是解决DM高可用问题，由于DM本身并不具有高可用性，可能一个DMworkerdown的时候能够支持自动拉起，但如果出现整个节点down的情况下其实是束手无策的。如下图所示，我们做了一个简单的尝试：
相当于把DM-master、DM-worker的所有的持久化的数据全放在共享存储上，DM-worker是通过容器启动的，如果发生节点宕机的情况下，只需要在备用机上把对应的worker提起来，并且关联到自己指定的DM-worker的共享存储上DM的路径就行。这里有一个问题是IP是固化不了的，所以在这个过程中还需要去变更DM-master的配置文件，之后做一次RollingUpdate。
场景三：数据生命周期管理
TiDB在VIPKID的第三个场景其实就是在数据生命周期管理。如果用过MySQL的都知道，其实大表在MySQL里维护起来成本是比较高的，所以一般很多公司会做逐级的数据归档。我们现在是根据具体业务，按照读写情况将数据划分成多个等级，并把其中温数据、冷数据，其实还有线上读流量的放在TiDB里。
这个场景里引入TiDB的考虑是要把数据的流转、运转起来的一个前提要保证冷热数据的表结构一致，但实际情况是，冷数据大部分情况下比热数据体量大很多，比如线上热数据做了一次表结构变更，比如加一列，同时如果冷数据同样要做这个操作，成本其实是很高的，可能是热表的十几倍或者几十倍都有可能，因此我们想借助TiDB来做这个事情。本身一方面TiDB的DDL有一些特性，加字段、减字段都是秒级的，另一方面就是借助TiDB本身的水平扩展的能力，我们可以每个业务端复用一套TiDB归档集群。下面再简单总结一下我们在使用TiDBDDL的相关经验，如下图所示：
左半部分我列了几个相对比较常见的DDL操作，比如删表、删索引，其实在TiDB里分了两步做，第一步只变更元数据，这时候就已经秒级返回给用户了，剩下实际数据的清理，是放在后台通过GC异步来处理的。而添加索引操作因为涉及到数据的填充和重组，所以这个操作的时间是依赖于数据量，但是并不会阻塞线上业务，我之前看了一下官方的介绍，TiDB中数据填充的过程被拆分为多个单元，每个单元内部并发进行读写操作。线上更常见的是删列和减列，在TiDB里跟MySQL的实现就不一样了，也只是变更元数据就行了，并不需要做底层的数据的rebuild，比如增加一个列，并不需要对原始数据再做一个回填，这里分两种情况，一种是默认值是空的，一种是有一个指定的默认值，其实只需要把这个默认值记录到TiKV里跟表结构记录在一块，当你查询这个数据对列值做decode的时候，如果是空的，直接返回空；如果是有指定的默认值的，直接返回指定默认值，并不需要对历史数据做变更。
场景四：实时数据分析的场景
还有一个场景就是做实时数据分析的场景，下图其实是最早TiDB在VIPKID引入的一个场景：
这个场景主要是BI分析师还有一些BI平台在用，架构上，相当于通过DM把线上的数据全部同步到TiDB里，借助TiDB的水平扩展能力，还有一些计算下推的能力，做一些实时数据分析。
TiDB4.0给我们带来哪些惊喜和收益？
TiFlash列式存储引擎
TiFlash是一个列式存储引擎，相对来说对AP场景更友好一些，并且他本身自己有计算能力，支持一些算子下推、计算加速。另外，TiFlash可以实时复制TiKV中的数据，并且没有打破之前TiKV的运行模式，它把自己作为一个Learner角色加入之前的RaftGroup里可以支持表粒度的同步；还有一个就是智能选择，TiFlash可以自动选择使用TiFlash列存或者TiKV行存，甚至在同一查询内混合使用以提供最佳查询速度，它已经不仅仅是单纯的一个SQL选择哪种存储引擎，粒度可以细化到同一个SQL里具体某个算子，比如一个SQL打过来，一部分可以走索引的其实走行存更快，还有一部分涉及到全表扫描的走列存，通过这种方式整体提高SQL查询速度。最后，TiFlash支持独立部署，可以跟TiKV独立分开，某种程度上做到了硬件资源的隔离。
下面谈谈TiFlash给我们带来的收益。
首先是性能提升，我这里做了一个简单测试，测试环境现在是有五个TiKV节点，一个TiFlash节点，有一个单表2.5亿数据，然后我对这个单表做count，在TiKV里走了索引的情况下跑了40多秒。而在单个TiFlash场景下10秒就跑出来了，这只是单个TiFlash节点，如果我再新添一些TiFlash节点，这个速度应该还可以进一步提高。
TiFlashTiKV第二是成本的下降，我们原来有一套给BI用的集群，现在用新的TiDB4.0的集群替换了，可以看一下下图左边的表格是新的4.0的集群各个组件资源分配比例，左边是新、老集群同样负载情况下的资源分配情况。可以看到，部署新集群让我们整体成本下降了35%。
第三TiFlash上线解决了一些稳定性的问题。之前在TiKV这一层如果跑了一些TP业务，这时候有一个SQL涉及到一个全表扫描，整个TiKV的集群负载就会变大，可能导致TP查询整体响应时间变长。现在我可以加入一个TiFlash节点，把对应集群里的大表自动添加一个TiFlash的副本，在这种情况下如果有一些类似的情况，可以优先会走TiFlash，而保证TiKV尽量不受影响。
再说两点我们在使用TiFlash过程中遇到的一些“限制”。
第一，如果你的SQL中涉及到一些TiFlash还没有实现的函数，其实是无法做到计算下推的，只是利用到了TiFlash本身作为列存的一个加速能力（注：如果有尚未实现的下推需求，可以与PingCAP官方联系技术支持，添加