作者：马超
“兵之道，运用之妙，存乎一心”。不久前PingCAP公司举办了线上发布会，正式发布了TiDB5.0版本。
现在数据库方面有两大流派，一个是非关系型（NoSQL）数据库，这是一种专门用来存储海量数据的Key-Value型数据库，主要用于用户画像、业务报表等海量数据的挖掘工作；另外一个是关系型（SQL）数据库，其针对个别记录增、删、改、查的速度很快，但很少做全表级别的大型关联计算，因此一般用于联机交易场景。简而言之，SQL处理速度快，NoSQL处理数据量级高。
之前SQL与NoSQL的应用场景两不重叠，井水不犯河水，但像直播带货这样的新场景不断涌现，由于在直播中的交易既要更新商家的库存和买家的帐户余额，又要根据客户行为进行实时分析、精确营销，类似这种综合SQL与NoSQL需求的业务场景不断涌现，使得混合负载HTAP数据库成为IT界所急需要解决的关键性技术，而这次的TiDB5.0打破了SQL与NoSQL两种场景之间的鸿沟。
如果用一句话概括本次TiDB5.0升级的精髓，笔者认为是“基于RAFT Log的行列混存，与MPP统筹的计算任务加速”。虽然看起来MPP、RAFT、行列存储等单独来看都平淡无奇，但把这些技术有机结合，就实属重剑无锋，大巧藏拙的设计了。
处理时效与灾备建设，数据库天空中的两朵乌云
权威咨询机构IDC对于大数据的定义是现有技术难以处理的数据。从历史来看，在谷歌提出大数据三驾马车的论文时，当时的关系型数据库技术就已处于难以处理大规模数据的状态。而在当下各行各业不断上云的大背景下，数据的量级必然还将不断创出新高，从笔者了解到的情况来看，整个IT行业存储的数据量级正在以年化80%左右的速度增长，传统SQL的数据库很难处理这样的数据量。
在TiDB5.0的发布会上，PingCAP CTO黄东旭分享了这样一段经历，他发现一个客户用TiDB跑一段大表关联的查询任务，效率非常低要半小时才能出结果，而这如果在TeraData的数据仓库平台上跑估计1秒钟就出结果了，他就问这个客户为什么要用TiDB跑这个任务，客户说如果把数据从TiDB上倒到数据仓库里需要半天，因此总体算下来，还是在TiDB上直接跑合算。其实这个例子也深刻说明了目前大数据技术栈所面临的窘境，各个数据库都是数据孤岛，打破孤岛之间的边界简直比登天还难。
以笔者所在的银行为例，目前一般在商业银行都使用Oracle数据库作为核心系统，但Oracle只能处理流程性的交易数据，不能做数据挖掘，要想把数据价值做二次表达，要每天做ETL、跑批作业、存到数据仓库中，然后在数据仓库中建模、挖掘、数据集市、ODS，一层一层地构建起数据仓库报表。
如果还回答不出非线性问题这样更细节更隐含的问题，就要把数据复制到SAS中做机器学习，再做统计的指标体系，以便做进一步的挖掘。数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作在做数据搬家。而数据在这种低效的转运迁移过程当中，很多价值也就白白耗散了，同时带来了处理时效和灾备建设这两个巨大的问题。
在处理时效问题上，正如我们前文所说，SQL与NoSQL两种产品底层构建模型并不相同，彼此兼容性不佳。这首先就会催生出数据处理的时效性问题，还是以笔者所在的银行为例，分析数据在交易核心数据库中跑批处理，再ODS抽取ETL分析到数仓，再进一步训练流式计算，最后再入湖，整个数据手动的过程至少需要一天。
而且Hadoop和数据湖的开源生态中很多组件并不兼容，日常运维已捉襟见肘，想提速也无从下手，但业务对于转瞬即逝的营销机会又如此渴求，T+1分钟可能都会嫌慢。对于处理时效的要求可能是大数据工程师与产品经理之间永远无法达成的协议。
灾备规划也经常被公司管理人员所忽略，大多数初创公司不会提前规划灾备体系。一般来说在两地三中心的灾备体系中，生产与同城中心是对称双活的，可以快速接管业务，异地中心一般是数据延迟同步，以应对一些删库、删表类的误操作。具体如下：
- 主中心：正常情况下全面提供业务服务；
- 同城中心：一般与主中心处在同一省份，主中心使用同步复制的方式来向同城灾备中心传输数据，保证同城中心数据复本为最新，随时可以接管业务，以保证RTO的指标。但是同城中心无法应对此类删库事件；
- 异地中心：一般使用延时异步复制（延时时间一般为30分钟左右）的方式向异地灾备中心传输数据，其中同步复制的好处是一旦主中心被人工破坏，那么不会立刻涉及异地中心，如此便可保证RPO的指标。
总结来说，灾备体系的最佳实践就是两地三中心。同城保证业务连续性，优先负责用户体验;异地保证数据连续性，确保企业生存底线。上云后的灾备规划也一定要纳入设计范围，一旦没有提前的规划，后续的补齐填坑的工作非常麻烦。但正如前文所说SQL与NOSQL两套体系的组件兼容性很差，能让两者协同工作已属不易，再考虑灾备真是难上加难。
行列混存的打开方式
从上面的介绍想必大家也能看出来，目前各个数据中心都迫切的找到一个一栈式解决方案，屏蔽底层组件的差别，打造“All Data In One”的解决方案，只有如此才能提高效率，低成本运维。而TiDB5.0一个产品内弥合SQL与NoSQL的鸿沟，在这方面做出了相应探索。
数据访问是受局部性原理所支配的，现代硬盘、内存工作原理是当用户读某一区域的数据时，其邻接的数据也会被调入上一级高速缓存，读1k数据和连续的64M数据代价基本相同，用户在读取连续的磁盘或者内存信息时，其速度往往比随机读取快一个数量级。
因此行存储大多用在SQL的OLTP场景，而列存储基本用在NOSQL的OLAP场景。这背后的原因也很简单，还是以我们银行业的情况为例，联机交易的TP场景下比如当客户取款时，会校验我的用户、账号、密码、余额等等信息，这些信息都是以行为单位存储的，联机交易中数据是经常是以行为单位访问的。
但是在统计、分析营业报表，进行数据挖掘等AP场景下，往往只需要关注交易金额、账户余额等少量几个维度的信息，而不需要什么用户、账号、密码等这些数据，而在这种场景下将同一维度信息放在一起的列存储方案就有很大的优势了。
而将行列进行混存，综合两者的优势，这方面业界倒也有不少尝试，但往往都不很成功，其最大的问题还是在于对于联机TP交易场景来说，列式存储的写入性能太低了，所以最后还是退化成为行式存储TP数据库在交易量少的日终时刻，将数据吐给列式存储AP数据库进行数据挖掘。
TiDB5.0没有用双写方案，而是将行存储TiKV与列存储TiFalsh做成一个基于RAFT协议的一致性集群，并使用RAFT log的将数据由TiKV与列存储TiFalsh上。
首先TiDB5.0行列混存的方案避免了之前列存储写入带来的性能损失。而且RAFT的一致性集群还保证了列存储TiFlash与行存储TiKV之间的数据GAP不会太大。而且这种方案还把TiFlash的数据同步工作完全封装在了TiDB内部，用户根本不用关心数据库的机制就能享受到TiFlash列存储与TiKV行存储的双重优势。
当然这还没结束，PingCAP还把MPP模型引入到了AP与TP的混合负载计算中，TiFlash也由之前单纯的列式存储引擎升级成完整的分析引擎，并与TiKV行存储进行了有机结合。用户在写SQL时根本不用考虑具体的业务类型，MPP模型会自动选择最优的计算方案。之前的MPP往往是单独针对行存储进行优化的，针对列存储优化的案例都不多，而TiDB将MPP方案用在了行列混合加速上面。
这样做的一大好处就是TiDB5.0还有一个大杀招，由于对外暴露的接口完全可以把TiDB与MySQL完全兼容，因此TiDB5.0完全可以直接作为MySQL的一个分片来接收数据，通过CDC的方式从MySQL的联机交易集群中拉取数据。也就是是不改动现有的核心系统，而是将 TiDB 作为现有核心系统的后置库。
TiDB通过解析 MySQL 分片对的 binlog，通过自动合库的方式将数据汇聚到 TiDB 的分布式集群上面。
在 TiDB 分布式集群上可以支持MySQL等纯TP数据库所无法支持的复杂计算、复杂的实时查询业务，这些业务负载可以从联机数据库直接迁移到 TiDB 后置库上进行。这样做的好处就是综合了NoSQL与SQL的优势，用户可以不费吹灰之力的完成一个灾备节点的建设，并且与此同时拥有一个实时的数据仓库，可谓一举驱散了数据库大厦中的两朵乌云。
最后笔者引用黄东旭的一个观点，“TiDB，包括PingCAP已经过去了它最危险的阶段，至少它现在已经是一个死不了的东西了，对于开源软件或者一个新技术来说最容易死在这个地方，现在这个地方已经过去了。”相信未来TiDB还将不断创新，降低系统数据管理者的运维成本，来创造更多价值。
