分布式数据库TiDB应用分析

本文基于TiDB技术架构与功能，以及已有实践，对分布式数据库TiDB的应用场景、发展定位及相关问题进行研究分析与探讨，关于TiDB的架构与组件网上已经有很多材料，本文中除了应用探讨中需要的描述外，不对此做专门系统性阐述。

1. 问题的提出

TiDB是近年来兴起的新一代云原生强一致NewSQL分布式关系型数据库，简单讲，就是：又能分布式、又能强一致、又是标准SQL驱动的RDBMS。这几个特性在传统关系数据库受到挑战，而新兴的分布式大数据技术栈又多属NoSQL，无法满足ACID强一致交易的关系型SQL数据库需求的时期，相当一段时间是数据管理新技术的空白区。因此，人们把满足这几个特性的数据库，称为NewSQL。创立初期，很明显NewSQL的目标是为了满足强一致分布式OLTP的需求而设计的，同时，OLAP分析型需求一直以来，开源也好，商业化也好，都不缺少好的技术与产品支持。不过发展近期，NewSQL数据库又都推出了在TP基础上增加分析型AP的混合负载能力，称之为HTAP，这里要讨论的TiDB正是如此。

我们的主要问题是，以TiDB为代表的NewSQL数据库，或者直接就说TiDB，究竟适合哪些应用场景呢？有些同学会说，“你这个问题不是多余吗？你上面不是说了，NewSQL是为OLTP创立的，那自然是最适合OLTP了！即使又加入了AP的功能，那应该是在满足TP的同时，再满足一些AP的需求了”。这样说，自然没有错，但在实践中，一是所谓的应用场景，繁多而复杂，即使是纯TP需求，也并不是如上这么简单原则描述就能准确覆盖的，遇到具体场景，对新兴技术大多还是会感到疑惑；二是HTAP中的AP能力，到底能适用到什么程度，具体哪些、何种程度的AP是不适合的？这些，在现实具体的应用场景中，有时可能连客户自己都说不清楚，甚至对同一类系统，不同的客户都有不同，而新兴技术又没有历史经验可循，自然也很容易同样感到困惑。

是否所有的TP系统都能满足？

是否只对有持续业务扩展需求的TP系统有优势？

是否云原生与开源才是最大的优势？

是否开放、完整的生态才是最大的优势？

HTAP中的AP究竟能满足到什么程度？

理论上与历史上讲，分布式是最先且更容易满足AP的，是否应该支持纯AP的应用？如果不能，是技术问题，还是商业定位问题，还是暂时投入不够的临时问题？

本文试图结合具体实例与应用场景，对以上问题作出回答。

2. 典型实践场景与技术架构的讨论

回答以上问题，需要从已有的典型实践场景与产品技术架构两个层面分别进行研习与探讨，然后经过综合分析得出结论。下文对TiDB实践案例的介绍，着重于场景本身的业务与特点，以及应用效果等的描述，不做详细介绍与深入技术点分析，至于在每个案例应用过程中遇到的具体技术问题、解决方法等，以及产品稳定性问题及发展过程，都不是本文的重点，因为所有产品的稳定性都有在实践中不断成熟的过程，与其定位与适用性无关。如果有同学对这些方面的技术细节感兴趣，可自行参考每个案例公开的技术文章。

2.1 典型实践场景研习

本小节先对TiDB的若干典型实践应用场景进行回顾与研究。

(1) 亿联银行TiDB

亿联银行从2018年初对归档库查询类交易需求尝试采用TiDB开始，直到2019年10月上线了第一个关键的联机系统：核心贷款系统。这是一个典型的ACID、高并发的金融场景，通过Chaos Mesh的全方位可靠性验证、悲观锁优化及热点账户改造等应用适配，以及同城市多数据中心多活，两地异地互备等策略的实施与测试，计划于近期正式上线。

亿联银行的TiDB案例是一个典型的银行核心业务系统应用，其中同时包括了联机交易、账务核算、跑批、在线查询统计与多地多活容灾等要求，TiDB的引入提供了高并发、强一致ACID、在线线性扩展、实时查询统计、一地多中心多活/两地业务互备等能力，很好的满足了典型金融核心业务系统：即强一致OLTP为主体，辅以查询与跑批兼顾的高可靠、高可用、高可扩展、高容灾要求的应用需求。

(2) 北京银行银联无卡支付系统

北京银行的银联无卡支付系统，是在2018年6月间进行了投产，该系统也应归类为面向OLTP的、金融核心领域的银行交易系统，经过多年的实践，较好地满足了其对高并发性、易扩展性、在线升级的需求。

值得指出的是，在北京银行，TiDB还实践了两地三中心五副本的部署模式，在两地距离上千公里，单向延时近20ms的条件下，通过一地两中心2+2四副本，另一地一中心1副本这样2:2:1的设计，在保证事务强一致性的前提下，一地三副本成功就可实时返回前端，达到SQL平均延时1.2ms，每天承载数百万笔业务的效果。

北京银行该案例本质上是金融级别纯OLTP的业务场景，同时还投产了网联系统与金融互联服务平台等重要的实时交易类系统。

(3) 丰巢核心业务系统

TiDB从2018年起取代Oracle与MySQL，承载了丰巢最关键的核心业务系统，协助客户解决了“传统单一数据库不能应对业务快速增长需求后，自行采用MySQL分库分表方案”而带来的“有状态数据一致性无法保证，不得不采用大量核对工具在系统间跑以保证最终一致性水平”，“大量原有正常的SQL需求无法满足”等等问题，在完全满足其日常业务交易及不断增长需求的同时，也以平均数分钟的水平，解决了原来大数据量的查询统计几乎无法完成的问题。

丰巢核心业务系统是典型的OLTP类互联网核心业务系统为主体，同时承载部分在线查询统计AP类的混合需求。

(4) 今日头条的核心OLTP系统

早在2018年，今日头条就采用TiDB承载其核心OLTP系统：图片、视频的对象存储元数据存储与查询，除了极高的交易性能需求外，也是今日头条所有OLTP系统中数据流量最大，QPS最高的场景：数据量日增5亿，QPS峰值20W/s；同时也承载了一部分原来加载到MySQL之上的OLAP分析查询需求。

今日头条的核心OLTP系统，也是一个典型的互联网类交易系统，对ACID强事务的要求并没有金融行业那么高，同时也是承载了部分在线查询统计的AP混合需求。

(5) 贝壳金服数据中台

贝壳金服于2019年，使用TiDB与TiSpark结合架构，建设了企业数据中台，目前已经同步了上游100多个MySQL业务库的数据到TiDB中，并通过TiSpark进行分析处理，现已达到近10TB的热数据，数百张离线和实时报表，同时中间还结合TiDB特性，实现了平台的在线不停机迁移；现阶段，已经在尝试新一代MPP列存储引擎，以进一步提升OLAP业务宽表查询的性能。

贝壳金服的数据中台，虽然是OLAP类应用，但本质上是面向数据消费的在线数据服务类支撑平台，这类应用在“以用为核、以管为基”的现代企业数据治理架构中已经逐渐成为一个重点，它并不是以批量数据加工为主体的企业级数据仓库。

(6) 陆金所的实时对账系统

陆金所随着业务不断增长，单库对账无法进行，不得不对业务数据库进行分库分表以后，基于大数据技术栈（Hive、Impala、Spark）实现的对账架构又无法实现实时对账需求。后将对账需求转移到TiDB，获得了实时增量更新、在线横向扩容以及实时多表关联查询等关键技术能力，满足了实时对账的业务需求。

陆金所的实时对账系统，本质上仍然是面向数据消费的在线数据服务类支撑平台，属于OLAP应用，但仍不属于企业分析类应用的核心设施：EDW数据仓库。

(7) 360金融贷款的实时风控场景

360金融贷款的风控应用，在使用TiDB之前，是采用了HBase+Neo4J的方案，可见其应用特点实际上是面向社交关系的图数据库需求。然而由于存储扩展与分析性能两方面的瓶颈，后将Neo4j中约70亿个vertex和相关edge数据移入TiDB存储，并基于SQL接口实现了部分如最短路径、多节点连通性检测等图算法。实践的结果是事务与风险分析的性能都得到了极大的提升：数据库平台峰值计算能力提升10倍以上，TPS指标提升至5000以上；同时风险分析人员可以直接使用SQL工具进行实时分析。

360金融贷款的实时风控应用，是一个典型的OLTP与OLAP混合负载的场景，同时证明了TiDB以关系模型替代图数据库的潜力。

(8) 知乎首页

知乎的注册用户数超过了2.2亿，其首页是负责把用户感兴趣的内容推荐给客户，以解决流量分发的关键入口，其核心逻辑是当用户访问时，负责拉取“用户感兴趣的内容”，然后过滤掉“已读”，再反回过客户端。这个业务流程并不复杂，但其特点是写入量与查询访问量极大：每日新增记录近30亿条，写入峰值40K+/s；每月增长上千亿条记录，目前有近两万亿条记录；峰值时间首页每秒要处理1200万份文档的已读查询，响应时间要求是90ms。这是一个典型的高可用、高扩展、高性能的互联网需求，TiDB在知乎的实践满足了这个要求，同时以同样的架构还满足了其反作弊的风控类业务需求。

知乎首页的TiDB应用是典型的互联网应用，对强一致的ACID特性并没有太多的要求，严格讲不算是TP，也不算是AP应用，姑且算做是需满足极端写入吞吐与在线查询需求的QTP应用吧，但在互联网行业中却是一个很有代表性的场景。

(9) 其它应用

TiDB还在各行各业的很多其它应用中发挥了积极的作用，如中国银联的实时查询数据中台（实时OLAP），光大银行的互联网核心代销余额宝 TA 核心数据库（HTAP），广发银行互联网业务中台（HTAP），小米手机桌面负一屏的快递业务与商业广告交易平台素材抽审的OLTP交易类业务，去哪儿网用于实现数据统计与OLAP查询的机器离线集群与金融支付数据集群，美团多个业务的OLTP类应用支撑（约200个物理节点，10个集群），还包括大量的海外应用，如日本大型移动支付公司PayPay的支付数据库、美国金融行业的历史第一单 —— 美国 Square、产越南最大支付公司 ZaloPay、东南亚最大电商公司 Shopee，以及近10个金融实时风控，近10个互联网电商实时风控，等等各种各样的丰富应用，TiDB在其中发挥了越来越多、越来越关键的作用。

2.2 技术架构的讨论

可以看出，TiDB目前的应用场景是非常丰富的，几乎涵盖了数据库管理系统可以支撑的方方面面，包括互联网金融核心系统、金融类OLTP业务系统、互联网类OLTP业务系统，OLAP分析类系统，批量处理系统，HTAP混合类系统，甚至还有对图数据库的替代案例。那么，是否可以基于此总结一下：哪些场景是TiDB适合的，哪些是不适合的？以方便对当前的业务决策做出有效的指导。这实际上并不是一个很容易的任务：如果将所有具体场景都列举出出来，显然太碎、太杂、太多，并且各种应用的技术特点其实很混杂、应用名称后面的实际情况又可能各自不一，也很难用名称来做出有效的代表（如上述知乎的首页应用）；然而如果只是给出一个粗的原则，如PingCAP官网上所列的“一致性高的金融业务、高扩展的OLTP、实时HTAP、数据汇聚与二次加工处理四大场景”的描述，又过于笼统，用来指导实际决策也稍显不足。

首先可以判断，OLTP类业务自然是适合的；然后就是OLTP中夹杂一些AP类查询统计，也是适合的；再就是HTAP混合负载类应用，自然是很有优势的；再者，从如上案例看，还有很多如数据中台、实时数仓类的纯OLAP类应用。这样看来，似乎是无所不能了？

其实，仔细分析的话，可以发现，对OLAP的支撑力度，是回答该问题的一个关键因素：即OLAP类的需求，究竟能支持到什么程度。抛开如上案例场景，从技术架构来看，TiDB总体上是分布式的架构，众所周知：分布式数据库架构最先是用来满足OLAP分析类需求的，即IOE架构的传统Oracle类关系数据库，即使除较强的OLTP交易能力外，其查询与分析的能力也并不差，但在应对纯粹的企业级数据仓库分析时，仍然明显能力不足。因此出现了分布式MPP架构的TeraData、GP等专门应对此类需求。加之TiFlash本身就采用了OLAP领域最先进的列存MPP架构，因此从技术架构上讲，TiDB应该是适合各类OLAP需求的。

但我们从实际场景来看，迄今为止，在OLAP领域，除了HTAP混载及面向在线数据消费类需求的实时分析外，少见有代表性的纯离线数仓类应用出现。

本文分析其原因可能有两个：一是目前在纯AP类方向的研发投入还不够，虽然架构适合，但对复杂的、动辄数百行的SQL处理，分析类的函数，以及ETL等生态，都需要定向的、一定时期的研发投入与时间积累；二是产品设计者的商业定位，还没有确定除了实时HTAP外，是否全面向完全替代MPP分析类数据库发展。总之，这不完全是技术的适用度问题。

3. 结论

那么，通过如上实际案例描述与分析，至此，是否可以得出一些相关的结论呢？

可以发现：企图通过具体的应用场景列举（如银联支付、网贷核算、互联网理财）来准确而全面的描述TiDB的适用场景，虽然在遇到同类/相似案例时会有很强的说服力，但很难做到全面而又准确；而现实中的应用场景成百上千，无法穷举，而客户业务也在不断发展创新（特别是现阶段），新应用层出不穷；并且即使同一个名字的应用在不同客户处的实质区别有时也很大。因此，结合架构与技术特点，列举尽量具体的可参考方向与判断原则，是比较实用的方案。本文对TiDB的适用场景列举描述如下：

1. TiDB可以适用于原Oracle与MySQL能支撑的所有业务场景，包括ACID保证的纯OLTP交易、在线查询、在线跑批及其综合等，它同时提供线用户透明的高可扩展能力；
2. TiDB的TP（行存）与AP（列存）相对分离又对外统一的架构在交易、分析混合的HTAP业务场景中，有着很大的优势，不但可以实现TP、AP业务的自动化、智能化分流、完美的资源隔离与在线扩容，同时还可以根据业务变化在线调整TP、AP的规模比例；
3. TiDB可以适用于以数据消费、数据服务为目标的实时数据查询分析需求与相关场景，可以称之为实时数仓、数据中台或者建立在数据仓库平台之上的数据服务平台，这是“以用为核”现代数据治理体系中的重要领域；
4. TiDB+TiSpark可以满足离线批量分析为主的数仓需求；
5. TiDB+TiFlash理论与架构上完全可以替代GP、TeraData、Vertica等专门的MPP分析型数据库，满足企业现代EDW（准实时/离线数仓）的需求。不过现阶段暂时由于在该方向研发仍需提高（复杂SQL执行计划的优化，分析类函数、ETL生态优化等），以及在商业策略上目前暂时并不以为此方向为主等原因，纯EDW目前并不是TiDB的重点应用场景；
6. 对于银行核心业务系统的替代，本文认为现阶段的主要问题并不是TiDB的技术适用性问题，而是银行核心系统复杂的应用生态（包括语言、丰富的渠道接入等等）迁移，以及应对银行核心系统极其特殊、严格的高稳健性要求的策略考量，虽然应该极为谨慎介入，但这里认为需要高度关注（国内已有极个别分布式数据库银行核心替代的案例进行）

         而对于相当多的银行目前采用的、对互联网业务单独设立互联网核心、与传统核心并行运行的双轮驱动的策略与趋势，TiDB用于应对这样的银行互联网核心则是完全可行的；

    7. 目前业务拓展中遇到的问题，大多是非云原生应用带来的维护能力考量策略问题，而不是TiDB本身的技术适用度问题。

最后要指出的是：从TiDB目前加入了MPP列存TiFlash的架构来看，技术上讲，它应该可以适用于信息科技数据库领域纯大多数的应用场景。随着技术的不断发展与成熟，OLTP与OLAP的界限将越来越模糊，用一套数据库技术（配套流计算、消息通道、BI、AI、ETL等生态工具）满足所有的业务需求，One Stack to Serve Them All，一定是现代数据管理技术发展的必然趋势。当然，至于有些同学在碰到关键型业务需求时，因为稳定性问题而对适用性存疑，这不在本文的讨论范围之内：因为任何一个数据库，都会有一个通过实践向更加稳定发展的过程，除不断研发测试外，通过关键实践机会提升产品质量水平，是必不可少的过程，这中间只是策略考量，没有技术考量。