作者：吴昕
在激烈的云数据库市场，一年韶光赢得浩瀚客户，OB Cloud 做对了什么？
如今，数据库市场正在迈入新的竞争阶段——一场云上的竞赛。
2022 年，中国公有云数据库市场规模首次过半[1]，估量未来占比将进一步扩大。许多中国的数据库厂商也捉住了云打算的发展趋势，积极进军云数据库。
但是，这并不随意马虎。许多企业已经在利用传统的数据库产品，要说服他们利用或迁移到云，须要打消客户对新技能的疑虑，办理数据迁移的技能和业务寻衅，供应强大的数据安全和隐私保护功能，以及，在担保产品质量和做事水平的条件下，供应具有竞争力的价格——以数据库产品的固有「粘性」，这是一件极难做到的事情。
云数据库市场的参与者浩瀚，每个玩家都在努力供应更好的产品和做事，争取得到更大的市场份额。
作为原生分布式数据库的领先产品，OceanBase 在 2022 年 8 月宣告推出云数据库 OB Cloud。经由一年的发展，OB Cloud 在环球赢得了浩瀚客户，包括新零售行业的海底捞、二维火和客如云，制造业的空想汽车，互联网行业的高德、携程、快手、作业帮、翼鸥教诲、GCash，以及跨境行业的洋葱集团、纵腾集团、递四方等。
OB Cloud 做对了什么？
本日就来看几个故事，理解 OceanBase 在公有云领域的技能之道。
RTO<8 秒，云上可享分布式数据库的最高可用性
2023 年 5 月，空想汽车自动驾驶和车云等系统批量上线 OB Cloud，以应对大量云场景带来的寻衅。这一决定的背后，是其产线运维系统在 OceanBase 上一年多的稳定运行，实践了 RTO（Recovery Time Objective，规复韶光目标）秒级的极致体验。
RTO 对汽车制造为什么主要？
汽车制造流水线是一个高度繁芜和自动化的系统，会产生大量的数据，包括机器数据（生产线上的各种设备和机器的运行数据，如温度、压力、转速、电流等）、工艺数据（产品制造过程的各种参数，如加工韶光、材料利用量、产品质量数据等），制造实行系统（MES）数据（如生产操持、库存管理、订单信息、物料需求操持等）。
一些大型的汽车制造商可能会每天产生高达数 PB（1PB=1000TB）的数据。
利用这些数据进行剖析，可以帮助制造商更好地理解生产过程、优化工艺，提高生产效率和产品质量。然而，处理如此巨量的数据须要强大的数据库系统，这也是许多制造商在数字化转型过程中须要面对的一个紧张难题。
随着空想汽车近年来的高速发展，产线系统的数据量激增，其数据库系统在处理大量并发要求或大规模数据时开始涌现性能瓶颈，对生产线的稳定运行构成了严重威胁。对车企来说，产线便是生命线，担保产线的平稳高效运转至关主要，产线上的任何一个别系涌现故障，都可能导致停产，而每一秒的结束都意味着巨大的人力和资源丢失。
在这样的背景下，空想汽车开始自研智能制造操作系统 Li-MOS，并急于探求一款极致稳定、可靠、扩展性强的数据库，以应对系统稳定性和高可用的寻衅。「OceanBase 投产至今，始终保持零故障稳定运行。」空想 DBA 卖力人赵海军回顾。
RTO 是一个衡量系统在涌现故障后规复正常运行所需韶光的主要指标。这个韶光包括了检测到问题、启动规复过程，以及规复操作直到系统规复正常运行的全部韶光，这一数字也成为衡量在线运用的数据库故障规复水平的核心指标。
2014 年，OceanBase 在业界首次提出 RTO<30 秒，并且全体故障规复过程完备自动不再须要人工参与，在当年双十一支付宝交易过程中环球首次做到分布式数据库不丢数据（RPO=0）、一直做事（RTO<30s）。如今，RTO＜30s 已经成为分布式数据库业界的事实标准。
2022 年，OceanBase 4.0 首次实现 RTO<8s，真正将故障规复韶光从分钟级降落到秒级。
从 30 秒到 8 秒，这短短 22 秒的提升看似大略，但背后涉及了大量技能和工程的寻衅。就像 F1 赛车比赛中的换胎过程，每一秒的缩短都是对技能、根本举动步伐、团队协作，以及最主要的，对运用处景和业务流程的深刻理解和精准掌握。
在 4.0 版本中，OceanBase 做了非常大的架构调度，把最底层的选举和同等性协议做了重新设计和实现，并做了大量的优化。选举方面，不再依赖于节点之间的绝对韶光，而是完备基于驱动，将全体选举 Lease 的韶光缩短到了 4 秒以内。不仅如此，在更上层的 RPC 框架内部重新设计了一套故障检测机制，当主节点涌现故障时，系统会直接进行有主的改选，可以在百毫秒的级别就把主的做事切换到一个新的 leader 上。同等性方面，所有的备节点都能实时并行地去回放主节点写入的内容，从而确保了在主节点故障后，备节点能够立即承担做事。并且，基于 Paxos 算法和动态日志流技能的创新，OceanBase 在单机模式下可以跑出超过MySQL 的性能，在测试场景下，可以做到靠近 200 万的 TPS。
作为共识协议的「本源」、容错性最好的 Paxos，其工程实现难度也是最大的。OceanBase 早在 1.0 版本就完全独立地实现了基于 Multi-Paxos 算法的日志同步机制，并在极致场景下打磨多年。正是由于一开始就完备自研，以是能够实现这些在底层架构上的创新。
升级至 OceanBase 后，空想汽车的产线实行系统数据库抖动频率均匀低落约 80%，对付常见的故障事宜真正做到了「先规复、后剖析」，大幅提升系统运行稳定性，结合智能运维体系，空想汽车的产线实行系统能够在无人值守的情形下，迅速完成故障的自动规复，实现汽车产线系统数据库的「无人驾驶」。
OB Cloud 完备支持 OceanBase 4.x 版本，供应同样的高可用做事。在产线运维系统已稳定运行 17 个月后，空想汽车决定，连续将自动驾驶和车云等构建于云上的数据库系统迁移至 OceanBase 的云上版本，连续在云上实现严苛的 RTO 目标。
极致压缩，用技能可持续降本
再来看一个故事。
作为菲律宾最大的电子钱包运用，GCash 被称为「菲律宾的支付宝」，注册用户 6000 万。然而，业务的快速扩展，其存储和打算资源本钱也呈现出迅猛的增长，给公司带来了巨大的本钱压力。
2020 年，GCash 日均交易量已达百万级，每个月都有超过 18TB 的新数据涌入，而且还在以大约 10% 的增幅连续上涨。为了处理这些数据，运维团队不得不投入大量资源进行数据拆分，不仅花费了大量的人力和韶光，还可能对系统的性能和稳定性产生影响。与此同时，数据存储空间的压力也在不断增大，数据库管理员（DBA）常常须要通宵达旦地进行数据清理和归档以开释存储空间。然而，这种办理方案只是暂时的，不能从根本上办理问题，反而进一步增加了运维本钱。
在最繁忙的时候，运维团队须要管理超过 200 个 MySQL 实例。面对如此大的业务量，系统很难平稳地进行变更以支持新的业务，在极度情形下还可能会涌现数据丢失。
GCash 急迫须要一个新的云上的存储办理方案，以应对数据快速增长带来的本钱寻衅。
终极，凭借高效、可扩展且高性价比的数据存储做事，以及 OceanBase 在金融支付领域的丰富积累，GCash 选择 OB Cloud 作为其新一代的存储底盘，OB Cloud供应了同 OceanBase 完备同等的数据压缩体验。
OceanBase 自研 LSM-Tree 架构的存储引擎，能根据数据存储的特色进行自适应编码压缩，供应高效的数据压缩能力。在过去做事用户的履历中，存储空间乃至可以降落到用户原有数据库系统存储空间的十分之一。
通过压缩来降落存储本钱是再自然不过的选择。但是，数据压缩终极目的是降本增效，降本不能捐躯效率，因此，实现高压缩比的条件一定是先担保高性能，其次，是做出更适宜实际业务场景的数据压缩。
通过利用自主研发的数据编码压缩技能，OceanBase可以根据数据类型和分布特性，自动选择最得当的编码办法，在担保性能的同时，实现高效的数据压缩。假设须要存储这 15 个数字：「0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233」。我们可以选择直接存储它们，每个数字占用一个存储单元，共须要 15 个存储单元。或者，我们也可以根据这串数字的特性——每个数字都是前两个数字之和，选择在一个存储单元中写入「前 15 个斐波那契数」。这样，相同的信息内容，存储的数据量却大幅度减少。更主要的是，这种压缩过程是无损的。当然，这只是一个简化的例子，实际的过程要繁芜得多。
除了能感知数据特色并按列进行压缩的数据编码（encoding），OceanBase还同时支持不感知数据特色的通用压缩（compression）。也便是说，可以对一个数据块前辈行编码，然后再进行通用压缩，从而实现更高的压缩率。
这些数据编码格式考虑到了对查询性能的影响。不仅如此，压缩的路径也经由设计，不会降落打算效率和解压缩性能。
结果显示，借助高效存储引擎和云上高速的块存储做事，OB Cloud 使 GCash 的数据存储空间节省了 70%，数据库资源本钱节省了 40%。这一结果大大超过了 GCash 的预期，为其带来了显著的效益，并使其能够更有效地做事持续增长的用户群体。
多级弹性扩缩容，应对流量常态化急剧颠簸
在现今的消费市场，新的流量模式和消费习气正在不断呈现。
每年的节假日，尤其是七夕、双旦，对海底捞这类餐饮及零售类企业至关主要。在数字化转型过程中，系统在流量波峰与波谷的处理能力也直接影响到业务。
海底捞的进销存系统，便是个范例例子。以 2021 年上半年为例，海底捞仅在瓜果蔬肉类的采购总金额就超过了 28 亿元，覆盖新疆、贵州、云南等 29 个省市自治区，数据体量非常巨大，丝滑的数据处理关系着食材品质和及时供应。
随着业务快速增长，利用传统数据库的进销存系统面临越来越多的寻衅。比如，全国门店的食材和物料进货、存储、发卖及供应等数据，以及数据实时变革带来的高并发问题；门店发卖单中的食材和物料变动必须与库存模块的数量保持同等，如果不一致可能会导致备货过量或缺货；订单状态不明确，会导致用户做事不到位，影响就餐满意度等。
每年的七夕、双旦，不仅是海底捞员工，也是系统数据处理最繁忙的时候，由于个别热销商品库存变革非常快，单条数据需支持秒级数千次的高变动频次，这也哀求系统必须能做到实时剖析汇总商品数量变革情形，以及时备货供应。
如何更灵巧、更安全、更低成本地实现数据库灵巧扩缩容，完美支持每次节假日的流量洪峰，成为海底捞最关心的问题。
为了更好地应对流量的连忙变革，海底捞的业务数据库须要具备灵巧的调度能力：在业务低峰期，以较小的规模稳定运行，减少资源摧残浪费蹂躏；在业务高峰期，快速扩容，以保障节假日的稳定运营。
针对海底捞的业务特点和需求，OB Cloud 以其从 OceanBase 继续的多级弹性伸缩能力，在云上打造了一个空想的办理方案。
在 OB Cloud 中，每一个业务（租户）拥有自己独立的资源。这些资源位于同一个资源池中，可以根据业务的实际需求进行动态调度。这种设计使得资源的利用更加精确，避免摧残浪费蹂躏。同时，这种设计也使得业务能够更快速地相应流量的变革，提高了业务的相应能力。
面对较大的业务流量，大略调度租户规格可能还无法知足业务需求，这时候就要在集群上做调度。在 OB Cloud 中，可以通过改变做事器的配置（垂直扩缩容），或者增加或减少做事器的数量（水平扩缩容）来适应业务需求的变革，而后者是 MySQL 等主备架构难以做到的。这两种扩缩容可以相互结合，供应更大的灵巧性，有效地应对流量的突增和突减，担保业务的稳定性和效率。
在刚刚过去的七夕节，海底捞进销存系统经受了两倍于去年的流量峰值，但基于 OB Cloud 的加持，提升了 45% 的系统实时剖析算力、降落 50% 的数据库整体本钱，从容应对了节日大考。
OceanBase 还在一个更高的层面，探索业务和架构的灵巧性：首次引入了创新的「单机分布式一体化架构」，小到利用公共云的个人小站点，大到利用私有云、稠浊云的银行核心系统、巨型电商网站，都可以在业务发展不同阶段根据自身特点，灵巧知足性价比和高可用的需求，而不是受制于技能被迫接管一些他们并不须要的能力。
这也引出了一个新的寻衅——如何在繁芜的云打算架构和多样的打算场景中，供应一种统一而且高效的云数据库办理方案。
支持多种云的根本举动步伐及稠浊云架构
云打算已经从初期的公有云和私有云，发展到包含多个数据中央的稠浊云架构。这转变也让我们向更繁芜的架构和稠浊云场景迈进。越来越多的企业开始在多个根本举动步伐上支配运用和数据，一方面利用稠浊云环境的灵巧性和快速相应，一方面可以为不同的运用处景选择不同的云根本举动步伐，充分发挥各个云做事的独特上风。
例如空想汽车，其生产线制造系统在数据中央进行私有支配，而车辆云和自动驾驶系统则选择了多个不同的云根本举动步伐，并且在公有云的多个地域进行支配，这样纵然部分功能涌现故障，整体做事也不会受到影响，担保车主的行车安全。
但是，这种模式也带来了很多技能上的寻衅：不同数据库产品在不同云根本举动步伐上的功能性能差异，增加了运维繁芜度和资源整合难度；传统单体数据库难以扩展并存在单点瓶颈问题，无法知足如车联网系统这样的多地访问的低延迟需求。此外，虽然某些数据库产品办理了扩展性问题，但它们的同等性协议对网络延迟敏感，可能导致在远间隔机房或网络环境不稳定的场景下产生写入抖动和做事不稳定，难以知足类似车联网、自动驾驶业务的低延迟哀求，等等。
面对多根本举动步伐的寻衅，须要一种灵巧、可扩展的稠浊云架构办理方案，能够统一管理和简化这些环境，同时还能供应同等的性能和功能。
OceanBase 不依赖专属硬件并能支持不同云根本举动步伐，它采取了无共享架构。通过利用 OB Cloud，空想汽车可以在数据中央支配整套 OceanBase 平台，也可以在不同的云根本举动步伐和云做事上供应同等的功能和管理界面，这大大提高了存储底盘的一体性和管理效率。同时，OB Cloud 的原生高可用架构可以在局部单点故障时快速自动规复，乃至在跨地域支配的情形下也能供应稳定的做事，确保像联网车机这样的关键系统的安全运行，担保车主的行车体验。
现在，空想汽车借助 OceanBase 打造环球领先的制造系统，并在 OB Cloud 上实现车云业务跨云异地多活，产线连续性和业务稳定性得到保障。
结语
OB Cloud 的一年表现，是 OceanBase 不断从结果出发，自我创新、自我迭代的印证。
中国拥有最弘大的数据根本，用户的运用最有可能催生原创建异。无论是技能还是工程，都要回归实际，一个参数的调度，毫秒级的偏差，都可能导致各种问题，须要一步步打磨，持续改进。过去几年来，OceanBase 拥抱开源和社区、推出云数据库，除了产品本身的研发，干系的文档、培训和配套方法也在同步推进。
正如 C++之父 Bjarne Stroustrup 说的，天下只有两种编程措辞：一种是为人诟病的，一种是无人问津的。
云数据库拥有巨大的发展潜力和前景，须要依赖全生态的协同才能成功。这是一个困难的过程，须要大量的投入和持续的努力。
终极，客户的口碑将是最有力的证明。
参考资料
[1]《数据库发展研究报告(2023)》，中国通信标准化协会，2023 年 7 月
