分布式数据库演进
关系型数据库(RDBMS) 起源自 1970 年代, 作为数据库其最基本的功能既： 数据的存储与组织模型，并在模型之上进行满足用户对数据计算的需求。在数据库发展早期阶段，有很多优秀的商业数据库产品，如 Oracle/DB2，在 1990 年之后，出现了开源数据库 MySQL 和 PostgreSQL。这些数据库不断地提升单机实例性能，再加上遵循摩尔定律的硬件提升速度，往往能够很好地支撑业务发展。随着互联网的不断普及特别是移动互联网的兴起，数据规模爆炸式增长，而硬件这些年的进步速度却在逐渐减慢，人们也在担心摩尔定律会失效。在此消彼长的情况下，单机数据库越来越难以满足用户需求，即使是将数据保存下来这个最基本的需求。
从 2005 年左右开始，互联网企业率先开始探索分布式数据库，首先带起了NoSQL 这波浪潮。这些数据库解决的首要问题是单机上无法保存全部数据，其中以 HBase/Cassadra/MongoDB 为代表。使用的场景更多聚焦于 AP 领域大数据系统与数据仓库，通过 NoSQL 数据库的水平扩展能力支撑起了互联网海量数据场景。然而在 TP 领域却鲜有分布式数据库，主要原因 OLTP 是面向交易的处理过程， 单笔交易的数据量小，但是要在很短的时间内给出结果，典型场景包括购物、缴费、转账等，需要关系型数据库支持 SQL、提供 ACID 事务保障，显然具有更好的通用性，在更广泛的场景中无法被 NoSQL 取代。这一点通过 NoSQL 十余年的发展已经被证明。
真正的分布式数据库的目标正是融合传统关系型数据库与 NoSQL 数据库的优势，而且已经取得了不错的效果。综上所述分布式数据库的定义是：服务于写多读少、低延时、海量并发 OLTP 场景的，具备海量数据存储能力和高可靠性的关系型数据库。
为了实现“分布式数据库”，在学术界与工业界的不断努力下目前市场主要有两大流派。分布式数据库在字面上可以分解为“分布式”和“数据库”两部分， 代表了它是跨学科的产物，它的理论基础来自两个领域。这同时也呼应了产品发展的两条不同路径，一些产品是从分布式存储系统出发，进而增加关系型数据库 的能力（NEWSQL）它的代表系统是 Google Spanner；另外一些产品是从单体数据库出发，增加分布式技术元素，在单体数据库上架设中间件基础上演进出来的， 被称为 Prxoy 风格， 较早出现的 PostgreSQL-XC（简称 PGXC）。
单体数据库的救赎
RDMS 系统做了不少努力来适应业务的变化，也就是上文提到的 PGXC 风格的关系型数据库的中间件和分库分表方案。在 PGXC 之前业务也做了更多尝试。
上古时代（客户端组件 + 单体数据库）
通过独立的逻辑层建立数据分片和路由规则，实现单体数据库的初步管理， 使应用能够对接多个单体数据库，实现并发、存储能力的扩展。其作为应用系统的一部分， 对业务侵入非常深。这种客户端组件的典型产品是Sharding-JDBC。
中古时代（代理中间件 + 单体数据库）
以独立中间件的方式，管理数据规则和路由规则，以独立进程存在，与业务应用层和单体数据库相隔离，减少了对应用的影响。对业务有一定侵入性，单体数据库 ACID 特性部分需要业务规避。这种中间件的典型产品是 MyCat/TDSQL/HotDB。
近古时代（单元化架构 + 单体数据库）
单元化架构是对业务应用系统的彻底重构，应用系统被拆分成若干实例，配置独立的单体数据库，让每个实例管理一定范围的数据。例如对于银行贷款系统，可以为每个支行搭建独立的应用实例，管理支行各自的用户，当🎧现跨支行业务时，由应用层代码通过分布式事务组件保证事务的 ACID 特性。
根据不同的分布式事务模型，应用系统要配合改造，复杂性也相应增加。例如 TCC 模型下， 应用必须能够提供幂等操作。在分布式数据库🎧现前，一些头部互联网公司使用过这种架构风格，该方案的应用系统的改造量最大，实施难度也最高。
综上所述：从单体数据库出发，增加分布式技术元素无异于在奥拓车地盘改装成
奥迪，它们共同的特点是单体数据库仍然能够被应用系统感知到，业务侵入性强， 研发过程中需要考虑数据库分片的变化所带来的代码改造影响。同时随着实例数的指数级增长，运维成本也随之增加。
NEWSQL 的兴起
是否有一款数据库，具备单机数据库的使用体验且能做到单机数据库的ACID 呢？2012~2013 年 Google 相继发表了 Spanner 和 F1 两套系统的论文，让业界第一次看到了关系模型和 NoSQL 的扩展性在一个大规模生产系统上融合的可能性。从分布式存储系统出发，进而增加关系型数据库的能力，每个组件在设计之初都是基于分布式架构的，不像 PGXC 那样带有明显的单体架构痕迹。
同时相比于单体数据库架构优势以外，NEWSQL 引入了两大创新以满足新型硬件与互联网场景。
- 高可靠：放弃了粒度更大的主从复制，转而以分片为单位采用 Paxos 或Raft 等共识算法。这样，NewSQL 就实现了更小粒度的高可靠单元，获得了更高的系统整体可靠性。
存储引擎层：使用 LSM-Tree 模型替换 B+ Tree 模型，大幅提升了写入性能 。
OceanBase 从 2010 年成立以来，在蚂蚁集团全金融场景经过了大规模的生产实践，支持自选主同步协议的数据库，在高压力的金融场景中实践检验 RPO=0， RTO\<30s，容灾切换真正做到无人干预；实现最完整的分布式逻辑及功能，如在透明的数据分区基础上实现了分布式读/写实时一致性（区别其他分布式数据库只能做到写最终一致性），实现了跨分区的全局二级索引等高阶能力，其分布式特性真正做到对业务无侵入，无感知。
OceanBase 技术特点
OceanBase 是一个高可用、可扩展、低成本、支持 HTAP 混合负载的分布式关系数据库，兼容 MySQL 和 Oracle 的语法。从使用者的角度看，可以认为是一个可以无限扩展且永不宕机的 MySQL 或者 Oracle 数据库。
基于 Paxos 的无损容灾和异地多活技术
数据库存储数据的可靠性和数据库访问服务的可用性、连续性是数据库管理系统的重要考核指标，传统数据库的主备同步机制需要在可靠性和可用性之间做🎧取舍。为了更好地满足业务的数据可靠性、服务连续性、高性能等需求，OceanBase 发明了基于 Paxos 的同步技术、异地多活技术和提前解行锁技术。在天猫“双十一”的运营活动中，支付宝 6100 万次/秒的数据库处理峰值的过程中，依然保证了跨数据中心的可靠性。
支持线性扩展的分布式事务处理技术
传统数据库无法支持水平扩展，当容量不足时，只能通过更好的硬件来提升处理能力。OceanBase 通过将数据库表格的分区自然地扩展到多台机器，应用负载均衡技术保证多台之间的数据和处理能力均衡，应用了参与者即协调者的事务提交协议将协调者的处理能力做到了线性可扩展，应用了全局版本号批量获取技术解决了全局版本号的扩展性问题，最终让整个系统的存储能力和服务能力均线性扩展。在国际事务处理性能委员会 TPC-C 评测中项目实现了 7.07 亿 tpmC，做到了世界第一，比 Oracle 在内的其它数据库高一个数量级。
基于 LSM 树的低成本存储压缩技术
在高并发数据写入下的低成本存储压缩方面取得了突破。数据压缩通常是处理海量数据存储的关键手段，但压缩往往会极大影响在线数据写入的性能，因此在已有的数据库系统中，压缩通常只是应用于离线场景，处理无修改或者修改极少的静态数据，很难应用于实时写入的在线场景。OceanBase 基于LSM 树，完成了一系列创新，在保障数据高并发写入性能的同时，极大地降低了存储的成本。应用于“双十一”蚂蚁金服的核心在线交易系统，支撑了极高并发的数据写入，并且与 MySQL 数据库相比相同数据的存储量只有接近 MySQL 的三分之一。
同一套引擎支持 HTAP 混合负载技术
传统数据库分为 OLTP 交易型数据库和 OLAP 分析型数据仓库，通过数据抽取、转换、加载（ETL）过程将数据由 OLTP 数据库同步到 OLAP 数据仓库。OceanBase 基于分布式架构处理海量数据的特点，发明基于时间片的混合负载调度技术、针对分布式场景的混合负载优化技术、针对分布式场景的并行执行技术，实现了在同一套引擎支持 HTAP 混合负载。对比基于 PostgreSQL 修改的 MPP 架构产品形态的国外先进数据库 Greenplum，该系统在 6 台服务器（每台服务器 96 CPU 超线程）上运行 TPC-H 100G 22 条查询的总时间只需要 86
秒，而 Greenplum 需要 161 秒，性能提升 87.2%。
总体性能指标
该系统于 2019 年 10 月和 2020 年 05 月两次参加国际事务处理性能委员会 TPC-C 测试，分别取得 60,880,800 tpmC （约 6088 万 tpmC）和 707,351,007
（约 7.07 亿 tpmC）的成绩，排名前两名，超过包括 Oracle 在内的其它数据库，其它数据库历史最好成绩为Oracle 30,249,688 tpmC （约3025 万tpmC。
该系统也是 TPC-C 的标准建立以来第一个通过测试并取得经过审计认证的正式结果的分布式数据库产品。
2019 年 10 月，在国际事务处理性能委员会 TPC-C 测试中，系统在阿里云 207 台数据库服务器机群上取得了 60,880,800 tpmC 的成绩。具体测试环境如下：
服务器：207 台，每台 CPU：Intel Xeon Platinum 8163 @ 2.5GHz * 64
（超线程），Memory：512GB，Disk：8 * 1788GB NVMe SSD
客户端：64 台，每台 CPU：Intel Xeon Platinum 8163 @ 2.5GHz * 64
（超线程），Memory：128GB
2020 年 05 月，在国际事务处理性能委员会 TPC-C 测试中，系统在阿里云 1557 台数据库服务器机群上取得了 707,351,007 tpmC 的成绩。具体测试环境如下：
服务器：1557 台，每台 CPU：Intel Xeon Platinum 8163 @ 2.5GHz * 84
（超线程），Memory：712GB，Disk：4 * 3570 GB NVMe SSD
客户端：400 台，每台 CPU：Intel Xeon Platinum 8269CY @ 2.5GHz * 104（超线程），Memory：384GB
图 11 TPC-C D 测试 图 11 是 TPC-C D 测试的运行曲线，在 1500 多台超大规模集群峰值压力的情况下依次杀死总控服务和数据库服务器，杀死总控服务对系统完全无影响，杀死数据库服务器大约在 1~2 分钟内自动恢复 100%负载，零数据丢失。 3. 国内外先进技术比较 项目支撑了世界最大规模的支付平台——蚂蚁集团支付宝平台，国际事务处理性能委员会 TPC-C 测试比同类数据库产品高 1 到 2 个数量级。该项目的故障恢复 RTO&RPO、扩展能力、存储成本以及分析类查询耗时等都优于国内 外同类技术。项目成果与国际前沿技术的性能对比具体如下表所示：
数据库未来趋势
数据库会随着业务云化，未来一切的业务都会跑在云端，不管是私有云或者公有云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」。
多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层通过权限，容器等技术进行隔离。
OLAP 和 OLTP 业务会融合，用户将数据存储进去后，需要比较方便高效的方式访问这块数据，但是 OLTP 和 OLAP 在 SQL 优化器/执行器这层的实现一定是千差万别的。以往的实现中，用户往往是通过 ETL 工具将数据从OLTP 数据库同步到 OLAP 数据库，这一方面造成了资源的浪费，另一方面也降低了 OLAP 的实时性。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。
在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被 Multi-Paxos / Raft这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都将是高度自动化的。
