本文来源：那海蓝蓝知数行云
数据库的发展，有很多推动因素。如硬件技术、AI技术、架构技术等都会对数据库技术的发展和变迁产生较大影响。但是，我们的思维，仅要局限于此吗？数据库的初心在哪里？
所以，我们需要思考：数据库革命式的创新，又会源自哪里？前面谈到共识协议，解决了数据库系统的系统级高可用的问题，这一问题是数据库的基本问题之一（三高一易）。能解决数据库的基本的、核心的问题，将会对数据库产生重大影响。
前面我们讨论了，诸如数据正确性和高性能以及易用性，这些都是数据库的核心问题，但又未被完美解决的，如果能够被完美解决，那么数据库工业将迈入一个新台阶。在2022年的DTCC上，我们就一致性相关的技术做过分享，该技术对于解决数据库正确性、解决并发算法的高性能带来帮助。
事实上，数据库技术的创新，其最大推动力，源自数据库自身的本质（这是用户需求确定的），也源自其巨大的不足（只是这些本质和巨大的不足之处，却容易被人漠视；如至今Oracle并不提供真正的可串行化隔离级别而使用者却习以为常）。
不断从数据库自身的不足上寻求突破，“数据库之未来，就在于专注于本心、本职、本职的创新”。
近几年，AI技术大火，同时带动了“AI4DB”大火。数据库技术有望在AI技术加持下，变得更加智能更加易用。
2023年，ChatGPT大火，同时进一步带动了“DB4AI”技术（如向量数据库），也带动了一些“智能助手”类软件。数据库的“智能助手”也火了起来，其背后，是大模型对数据库知识的集成使得“数据库知识平民化”，这将进一步使得数据库的易用性得到提升。
更进一步，如果我们不只把数据库的“智能助手”置于数据库的前端，只用于生成SQL语句或改变数据库的输入等，而是让大模型技术还能接管数据库的输出、能配合数据库的可观察性而实现数据库系统的自动管理和调度，则数据库的易用性会进一步得到大幅提高。
如果我们能不断反思数据库的本质、不断结合新技术解决数据库新需求和已知不足，那么数据库将有一个更加美好的未来。
分布式数据库的发展，如图6和第一节所述，已经经历了两个阶段。但是第二个阶段的产品，仅仅是做到了“可实用”但不够好用。我们期待，未来一代的数据库产品，能够真正让数据库变得好用起来。
在三高一易的背景下，需要新一代数据库产品，具备明显区别于前两代的技术特征，如图7，也就是第三代分布式数据库至少需要解决的核心问题包括：极简的易用性、可控时延的高可用性、100%的数据正确性。这也将是第三代分布式数据库的核心特征。
解决数据库产品的易用性的问题，极简的易用性，包括三个层面的含义：
1.1 第一是易理解性：数据库中涉及的理论自洽可100%解释，即能把相关的知识体系融会贯通而使人信服，不存在知识困惑点而无法理解和解释，这是一个产品体系最基础的部分，能够减少用户的学习成本，称之为易理解性。易理解易学习是对于所有人而言的易用；
1.2 第二是易维护性：数据库产品功能与组件易增减易演进，使得数据库自身具备好的扩展性，这是从数据库内在架构的角度来看待的，它影响着一个数据库产品的可维护性和可长期发展性，称之为易维护性。易维护性是对于内核研发人员而言的易用，如果一个数据库内核不易被长期维护或永生，则建立在该产品上的系统亦将短命；甚至在未来，如果一个软件产品不具备易维护性，则采用类似ChatGPT等技术进行数据库引擎自动编程则未来难以可期；易维护性是对于数据库引擎研发人员的易用，更是对数据库内核引擎的生命维护的易用；
1.3 第三是易使用性：数据库产品能够尽量的自动化、智能化，减少用户的使用、运维、管理成本，减少DBA和专业的设计与开发负担，简化与减少需要用户参与的交互参数，对数据库的输入和输出能够自动分析，对数据库引擎内核能够进行自动监控和智能调度，使得数据库系统具备高度的智能，称之为易使用性。易使用性是对用户而言的易用；
这三个层面从原理、实践角度，从研发和用户角度对第三代分布式数据库做了总结，合称为“极简的易用性”。
是一个极其复杂且充满挑战的问题，其复杂度不在于理论层面是否完备，而在于架构设计时的所秉承的架构设计理念和工程实现过程中对内核组件的把握程度。
2.1 数据库的高可用性，分为三种类型：一是跨地域高可用性，用以实现异地容灾，Paxos/Raft等共识协议是一种实现异地容灾的技术选择；二是跨节点的高可用性，用以实现计算节点的高可用性，Paxos/Raft等共识协议或是传统的主备复制技术可做技术备选；三是事务高可用性，用以解决事务级别的高可用性问题；
2.2 事务级别的高可用性问题，在于解决Daniel J. Abadi在《Consistency Tradeoffs in Modern Distributed Database System Design》中提出的“PACELC”[1]问题。
用户业务类型丰富，不同类型的业务，对于时延、对于是否在事务管辖下执行，有着不同的需求。纳秒级的应用、毫秒级的应用以及秒级等的应用，有最大时延范围的要求，最大时延是根据业务对时延的不同要求进行类型划分的一种重要方式。而高时延意味着系统面临着“逻辑不可用”（传统数据库的事务尾延迟居高不下使得数据库在逻辑层面达到不可用的程度，而CAP中网络分区事件是“物理层面的不可用”）。
因此，在谈及高可用时，必须增加“可控时延”作为对“高可用性”的限制，这种限制对于数据库架构的设计有着至关重要的作用，不同的时延，需要不同的系统架构，需要考虑不同的因素。例如，传统的磁盘型单机数据库MySQL、PostgreSQL等，一个事务完成的时延，通常在20毫米之内，基本能满足金融业务的需求但不能满足更短时延的应用；但是如果把他们分布式化，或者提高并发压力，则这些系统的时延尤其是P99时延会大幅增长，使得他们很难在高并发场景下被采用。
故此，第三代分布式数据库的设计，需要着重考虑时延而进行设计，而不是像传统的数据库系统先有系统后让应用完成对既有数据库的适配工作，因此可控时延的高可用，是对数据库高可用性的进一步要求。也将成为第三代分布式数据库的重要特征之一。
2.3 可控时延的高可用性，指的是事务级别的高可用性，是事务在物理网络分区发生和较长时延下事务的处理和应对方法，该方法是一套体系化的应对方案，需要在事务管理器中有明确的处理方案；传统的数据库系统对事务的实现方式，主要在于采用并发访问控制算法实现事务的“保序”调度，其缺乏一个事务管理器的角色，对事务进行精细化、一体化的管理，确保事务的可用性得到实施。
解决各种应用对于数据正确性的隐忧，从根本上消除数据的正确性问题，同时兼顾数据库的性能的问题，因此也是第三代分布式数据库的基础、核心问题。
如上三个特征问题，自数据库诞生之日起即存在，一直没有被彻底解决，尤其是数据正确性和性能都被确保的问题（数据正确性和性能这鱼和熊掌可兼得），制约了数据库技术进一步发展。这些问题被第一、第二代分布式数据库所遗留至今久拖未解，势必成就第三代分布式数据库系统。
本节提出的极简的易用性、可控时延的高可用性、100%的数据正确性三个基础且核心的特征，可作为第三代分布式数据库的设计目标。其中，遵照CAP和PACELC原理，分布式事务型数据库需要优先确保一致性，因此事务处理技术成为三个特征中最核心的问题，需要在架构层被优先考虑。
待续，下一篇，我们将谈谈：如何阅读一致性八仙图？
大会上我们分享了这一核心技术，如图8（一致性八仙图），该图所示技术有很多特点，如下参见与Jespen的对比表1。好多同学会后问该图详情，内容重要且较多，如下单独成文进行介绍。
表1 一致性八仙图所用方法（简称八仙方法）与Jespen的对比T型表
| Jepsen | 对比内容 | 八仙方法 |
|---|---|---|
| 能（只能穷举，但所基于的理论尚未被证明能覆盖所有情况） | 理论层面能覆盖所有情况 | 能，但更精细精准 |
| 不能（单次测试只能随机构造有限的用例） | 实践层面能覆盖所有情况 | 全面覆盖（测试用例不随机，全面覆盖） |
| 特别高（测试时间随测试覆盖范围增长而增长） | 测试成本 | 几乎零成本（对硬件和时间无要求） |
| 不容易，单独使用、单独测试 | 容易集成到回归测试用例中 | 非常容易 |
| 每次都随机构造，一次性构造一次性使用 | 测试用例的生命周期 | 一次构造，永久使用， |
| 可短可长（有限时间构造有限个数用例） | 单次测试时间 | 分钟级完成（固定个数的用例） |
| 特别复杂，需要运行特定程序构造人类难以看懂的环 | 每个测试用例构造复杂度 | 非常简单 |
| 几乎不能（靠运气复现） | 错误是否可复现 | 100%可复现 |
| 不容易分析定位问题（测试用例是边长个数不确定的环） | 复现后的错误是否容易分析 | 容易分析定位问题（测试用例是最精简的最少边长的环） |
历史阅读：
第三代分布式数据库（1）——踢球时代
延伸阅读
▼
《分布式数据库原理、架构与实践》
推荐语：腾讯T14级别专家、腾讯金融云数据库首席研究员、腾讯TDSQL首席架构师执笔，从原理、架构、案例三个维度深度剖析分布式数据库所涉一致性、高可用性等，人大教授等鼎力推荐
本文来源：那海蓝蓝知数行云，图片来源：那海蓝蓝知数行云、pexels
责任编辑：王莹，部门领导：卢志坚
发布人：白钰
