腾讯TDSQL提出三个“数据库之问”，数据库技术将来重点在哪？
做者简介： 李海翔，网名“那海蓝蓝”，腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术：事务管理和并发访问控制》、《数据库查询优化器的艺术：原理解析与SQL性能优化》、《大数据管理》。算法
前言
2019年10月11日至13日，CCF数据库专委会在济南召开了国内规模最大的、每一年一度的数据库学术盛会——第36届CCF中国数据库学术会议（NDBC 2019），腾讯TDSQL团队受邀在“数据库产学研合做论坛”，作了主题为“TDSQL对将来分布式数据库的技术研发思考与实践”的技术报告，与国内数据库学界与业界核心技术人员共同探讨国产数据库面临的基础问题和技术发展方向，助力推进我国数据库技术自主可控发展。数据库
与此同时，本次会上，腾讯云数据库技术专家、金融级分布式数据库TDSQL团队专家工程师、中国人民大学信息学院工程硕士企业导师李海翔，当选成为了中国计算机学会（CCF）数据库专委会委员。将来，腾讯将加大投入，促进我国数据库产学研合做，推动数据库技术自主可控发展。安全
做为致力于基础技术研发的科技公司，本次NDBC 2019会议，腾讯TDSQL团队带来了TDSQL对分布式数据库技术研发的深度思考与实践分享，期待能抛砖引玉，引起更多思考。主要包括三个方面：性能优化
1） 分布式事务的效率与正确性，如何在保证双一致性（事务一致性、分布式一致性）的前提下，提升分布式事务型集群的处理效率？ 2） 新硬件和AI等技术，在云环境下，如何影响着数据库的架构？ 3）数据库各个模块间是否能解耦以下降研发的复杂度，同时缩短研发人才的培养周期？markdown
一 腾讯TDSQL数据库的发展历程
TDSQL是腾讯打造的金融级分布式数据库，对内支撑腾讯公司近90%的金融、交易、计费类业务。2007年，随着公司业务再一次腾飞，TDSQL团队启动了一个7*24高可用服务项目，以保障腾讯计费等公司级别敏感业务高可用、核心数据零丢失、核心交易零错帐。这也是TDSQL的前身。网络
然而，考虑到当时选用的技术方案，技术层与业务层耦合较深。因而，腾讯技术团队开始了研发一款金融级数据库的项目。实现让数据库来解决高可用、数据一致性、水平伸缩等问题，而让业务系统只须要关注业务逻辑。2012年，标准化的金融级分布式关系型数据库产品TDSQL研发完成，并在腾讯内部大规模推广使用。数据结构
十多年研发演进中，TDSQL在高可用、分布式方面作持续优化，同时不断提升性能，具有全球部署架构、水平伸缩、企业级安全等特性。架构
例如，2018年，TDSQL实现了原创性提出的全面地解决读一致性的算法，使得分布式事务的一致性和分布式系统的一致性统一在一块儿。同年，在业界颇为头疼的云数据库运维问题上，TDSQL还提供了两大利器：“赤兔”运营管理平台和“扁鹊”智能DBA诊断系统。并发
从2014年开始，TDSQL经过腾讯金融云平台对外开放。目前TDSQL已经为500+机构提供数据库的公有云及专有云服务，客户覆盖计费、第三方支付、银行、保险、互联网金融、物联网、互联网+、政务等领域，助力客户业务从国际数据库切换为自主可控的分布式数据库。运维
今年，腾讯云TDSQL助力张家港行成功将银行传统核心系统由集中式数据库存储改造为分布式数据库存储，这是在国内银行首次在传统核心业务系统场景下，采用国产分布式数据库，打破了该领域对国外数据库的长期依赖。
二 TDSQL的分布式事务处理技术：高效的分布式事务双一致性
首先，咱们分享一下TDSQL在实现“双一致性（事务一致性、分布式一致性）”，并提升分布式事务型集群的处理效率的探索实践。
众所周知，数据库是一个高并发系统，全部的操做经过事务的语义加以约束。而事务的语义，表现为事务的四个特性——ACID：原子性（A）、一致性（C）、隔离性（I）、持久性（D）。而一个数据库系统，其最核心的技术，就是事务处理技术。为了保障ACID，数据库使用了多种复杂技术，其中，技术的核心是并发访问控制算法。
事务处理技术，有两个初衷：一是数据正确性，二是并发高效率。TDSQL的分布式事务处理模型，经历了2代，第一代采用的技术是2PL+MVCC，第二代采用的是OCC+2PL+MVCC。OCC技术融合了2PL以解决高冲突不能高效率的问题，OCC融合了MVCC消除了读写、写读互相阻塞的并发问题进一步提升了性能，自适应的OCC使得在OCC和2PL间动态自动切换，使得分布式事务处理机制更聪明。
可是，这些还不足以体现TDSQL如何着手提升分布式事务的效率。在架构上，TDSQL是去中心化的架构，没有集中式单Master那样的处理分布式事务的单点瓶颈，事务协调器间传递相关联的分布式事务控制信息量被优化，分布式并发访问控制算法的冲突粒度控制在数据项一级从而提升了事务的并发度，于是效率更高。另外还有不少其余方面的优化，使得TDSQL的分布式事务处理效率较高。
而咱们继续探讨，如图1，在分布式背景下，怎么实现“双一致性（事务一致性、分布式一致性），并提升分布式事务型集群的处理效率？”
该问题，是业界一个难题。Google的Spanner系统实现了双一致，但事务处理的效率很低。TDSQL在深刻研究分布式事务处理的技术时，不只解决了全局一致性问题（2019DTCC大会分享：分布式数据库全局读一致性），并且提出了一个“统一致性模型”，不只在正确性上实现了双一致的功能，并且高效地解决了该问题。
在TDSQL看来，双一致性的正确性相对容易实现（尽管这也是一个很难解决的问题），但分布式事务型数据库的性能难以有效提升。
那么，有哪些因素，制约着分布式事务型数据库性能的提升呢？
如图2，一些研究者认为，是网络带宽限制了性能；一些研究者认为，制约分布式事务型数据库性能的提升有2个因素，一是“latency”自己，二是“latency”延长了事务的生命周期，而长的事务生命周期致使并发事务发生冲突的几率增大，进而引起事务回滚下降了性能。
另外，影响正确性和性能的，是事务处理技术中的核心技术——并发访问控制算法。
如图3所示，实验代表，在事务型数据库中，OCC算法效率更高，在多核环境下，OCC算法比2PL算法性能高出170倍。可是，高的并发冲突下，OCC的回滚率增长，代表OCC算法的缺点也很明显。
可是，还有研究者对于多种并发访问控制算法进行了较验证，如图4，发现传统的OCC算法比不少种知名的改进的OCC算法（如知名的Tictoc、自适应的OCC等算法）更有效。这代表，不一样人实现的不一样的系统尽管采用了同样的算法思路，可是实际效果却大不相同（如Tictoc自身的测试结果代表其改进的OCC算法效率好于传统的OCC算法）。因此，咱们在思考，不一样实验获得不一样的结论，其背后，真的影响分布式事务的效率的因素到底是什么？
进一步探讨，如图5所示，不一样研究者代表，自适应的OCC（OCC+2PL），有着更好的性能（图5中间的子图）。综合图三、图4和图5，其实能够发现，不一样的研究者的验证结果，是不能互相推证的，他们的验证结果，只能代表算法之间的大体趋势（如OCC性能会比2PL更好一些）差别，但不能精确代表算法之间的差别点究竟在哪里。
再对比图6，腾讯在MySQL上作了热点更新功能，发如今高并发高竞争同一个数据项的状况下，影响MySQL性能的，不是2PL这个算法自己，而是为解决死锁问题时死锁检测算法消耗的CPU资源，故MySQL的事务吞吐量近乎为0。禁止了死锁检测后，并用系统锁（非事务锁）互斥了在同一个数据项上的并发竞争后，MySQL系统事务处理吞吐量上升的万倍左右。
这说明了，在不一样系统下实现的相同算法的结果，只具备参考价值。若是在实际系统中，如MySQL、PostgreSQL中作实现，才更有实际参考意义。
三 分布式数据库的架构与解耦
TDSQL团队在研发分布式事务型数据库的过程当中，除了思考分布式事务处理技术（ACID实现的全部技术）外，还深度探索测试验证、架构扩展、模块解耦等等各类重要的问题。
新硬件和AI等技术，在云环境下，如何影响着数据库的架构？ 数据库各个模块间是否能解耦以下降研发的复杂度，同时缩短研发人才的培养周期？
新硬件和AI等技术，从架构上深深地影响了传统的数据库，这表如今如何融合这些新技术：
首先，数据库可能会“增长”不少新模块进去，如图7中的左下子图，AI调优数据库技术使得数据库系统被扩展了，增长了不少新组件进来。
其次，数据库的传统模块会被改变，如图8中的左下子图，在并行的事务型数据库系统中，提出基于AI技术对事务进行优化的模型。该模型采起存储过程的方式（此点相似H-Store、VoltDB），向数据库引擎提早提供所执行的事务，而后利用AI技术（Markov model，马尔可夫模型）对存储过程进行分析，肯定那些存储过程所表明的事务间的语义，排定事务并发执行时哪些是互相冲突的，获得一个有固定结构的事务执行模型，如图8左下子图中右侧，是对TPC-C模型NewOrder进行的分析获得的事务调度图。
当多个Client发出SQL语句执行存储过程表明的并发事务时，据此模型即能推断事务的调度方式。这是AI技术改变事务处理中并发访问控制模块的一个典型事例。
图8中的右上子图，是RDMA对于事务处理技术的影响，该图展现了四种模型，其中“d”模型是基于RDMA从2个方面对事务处理构成影响，一是事务处理的控制流，二是事务执行过程当中发生的数据流。影响分布式事务处理效率的，不只仅是庞大的数据流，而相对数据量小的控制流，也是瓶颈，所以须要引入RDMA来加以解决网络带宽瓶颈。
传统的数据库系统，其复杂度极高，从外看高内聚，从内看高耦合，这使得数据库的复杂度骤然提高。当各类新技术产生，影响了数据库的架构时，数据库的复杂性被再提上一个台阶。在这种背景下，研发人才的培育，其成长周期就会更长。所以，咱们在思考的一个问题是：从技术上看，如何解耦数据库内部间的诸多模块？耦合度高，研发人员须要掌握数个相关模块才能良好推动工做；若是模块间解耦较好，掌握单个模块就能方便推动工做，这样人才的培育周期相应也会缩短，软件的质量也会获得提升。
因此，数据库架构背景下各个模块解耦问题，是一个技术问题。解耦工做，能够在许多层次、许多模块间展开。解耦技术，各有其妙。
如图7右上子图所示，AWS的Aurora提出的存储计算分离，就是存储和计算两大模块的解耦。而微软Deuteronomy系统在08年-16年也有过一系列相关工做。Deuteronomy一开始采用的方案是在存储层上面实现事务，而底层的存储采用的是KV模型。存储层只须要提供KV的原子性和幂等性，上层就能够比较容易实现事务的并发访问控制和恢复。后来的Percolator、Spanner/F一、CockroachDB、TiDB其实也是沿着这个思路在发展，底层是Bigtable/Spanner或者RocksDB这样的KV存储引擎，在存储之上封装一层事务。可是在相似RocksDB这样的KV存储中，对于KV记录的并发控制仍是和存储紧耦合的。
存储和计算两大模块的解耦，促进了各自所囊括的子模块之间再次进行解耦，如图9所示，事务和存储层的解耦，该怎么进行？有的研究者，把事务处理功能提取到客户端进行（图9左子图），有的把事务处理功能放到中间件层实行按（图9中间子图），这2种方式不一样于传统的在Server端进行事务处理（图9的右子图）。
另外，解耦工做，其实无处不在。图10展现了算法与数据结构之间的解耦。图10的左子图，是数据库的持久化部分和内存中数据之间的设计解耦。图10的右子图，是索引的数据结构与物理存储层之间的解耦。
图10的左子图，对应VLDB 2018的论文"FineLine: Log-structured Transactional Storage and Recovery"，提出了一种事务存储和恢复机制FineLine，舍弃了传统的WAL，把全部须要持久化的数据存储到一个单一的数据结构，但愿将数据库的持久化部分和内存中数据存储之间达到设计解耦。
FineLine无需将内存中数据落盘到DB，仅将内存中的log信息持久化到Indexed log中，而后经过fetch操做从Indexed log读取到数据的最新状态。经过将内存中的数据结构与其持久性表示尽可能地解耦，消除了与传统基于磁盘的RDBMS相关的许多开销。除此以外，这种单一的持久化存储架构带来的另外一个好处是，在系统发生故障后恢复的开销很低。因为Indexed log保持了与原子操做的一致性，当发生故障并重启时，能够从Indexed log中读取到已提交的最新数据记录。基于no-steal的策略，Undo操做，Checkpoint这些也都不须要。
数据库内部，各个模块之间的解耦，与模块粒度的划分，与具体实现的系统，都有密切关系。如图11展现了几个主流数据库之间解耦的关系，期待能抛砖引玉，引起更多思考。
结语
数据库做为核心基础技术之一，在自主可控的时代发展潮流下，是咱们必将要跨过的大山。路虽弥，不行则不至，历经十数年的研发演进，至少今天咱们都已达成了许多重要的里程碑。当下而言，国产数据库从技术、人才、工业生态等各方面，都有待完善和发展，而将来更紧密的产学研结合、科技与传统产业融合趋势下，将进一步促进数据库自主可控发展。