为什么说是浓缩？因为我们最初是从 20 世纪 70 年代的数据库论文读起，从分布式系统的研究一路走到互联网时代的架构，再到今天的 AI 需求。数据库过去六七十年的技术演进，我们有幸在过去十五年里几乎全程跑了一遍。因为我们面临的时代和挑战完全不同，最终做出来的产品，和经典数据库有所不同。

为什么会不一样？我们确实读过几乎所有的经典论文，也学了全球经典的技术经验，但我们身处不同的时代已截然不同，业务需求变化更快，挑战更加复杂。面对新一代的基础设施环境，我们必须走出自己的路，正是在这样的背景下，OceanBase一体化架构应运而生。

OceanBase 为什么要“一体化”？

究竟有哪些不同？先从需求说起。

刚刚诞生的时候，企业处理数据或者面临的需求还是相对简单的，但是现在我相信任何一家企业至少要面临一个很重要的挑战——那就是发展的速度越来越快了。

发展的速度带给企业的最大挑战就是解决所有问题的效率要高，不仅是解决一个具体问题的效率要高，而且可能要面对不停变化的新需求，以及如何支持新的挑战，企业转型的效率要高。

同时，激烈的竞争，还非常强调对成本的把控，所以在提效和降本方面，现在的应用层其实对底层提出了越来越多的挑战。

此外，我们面临的数据和基础设施也发生了巨大变化。 过去，企业处理的数据模型相对简单，但随着时代发展，企业系统，包括 IT 系统、ERP、CRM 等各类平台需要处理的数据类型日益复杂，从用户行为分析到安全风控，数据形态也从结构化、半结构化演进到如今由 AI 大模型驱动的海量非结构化数据。

这种数据层面的演变，对底层数据架构提出了更高要求，也带来了更大挑战。

再者，这些年新硬件平台不断发展，从服务器到虚拟化环境再到云，都经历了自主技术迭代过程，这些都为基础设施带来新的挑战。

解决这些问题，有很多方案。在处理高并发、高性能的大规模业务时选择一种方案，针对周边系统或者简单的查询选用其他方案，数据分析和价值挖掘则采用另一种方案，云下、云上的环境也分别对应着不同的技术。再加上近两年大模型的不断迭代，又面临文本向量化检索、RAG 等新需求，需要不断引入新的系统。这种常见的解决思路，虽然能满足不同业务需求，但也导致企业内部拥有大量的系统和割裂的数据生态。

在这种情况下，企业不仅要处理数据同步等问题，还需要让不同系统协同发挥作用，业务开发也变得更加复杂。同时，运维和支持团队必须学习各类技术栈，以确保顺利支持各类系统。而且，随着企业对安全要求的提升，安全管理面临更高挑战：不同系统的安全水平不一致，如何针对不同系统，打通全局、满足企业和行业对安全的合规要求，成为亟需解决的重要问题。这些复杂性正是 OceanBase 提出要用一体化架构来应对现代企业多样化需求的原因。

一体化不是简单地把刚刚提到的诸多困难或对应的系统粘合在一起，它是一种架构理念。就本质而言，数据处理的核心在于如何有效地封装、架构计算、存储、分析、检索这四大基础能力，并为上层应用提供支持。

虽然现有的不同系统能够分别解决某一类问题，但系统之间往往存在大量技术、部署和数据层面的重复。一体化架构正是要以新的技术思路，系统性地解决这些重复和割裂的问题，实现更高效的资源整合与数据协同。

15 年演进：从核心系统到 AI 驱动

当前数据呈爆发式增长，企业在开展新业务时，初期数据量可能较小，但很快就会超出现有硬件的承载能力。这时，企业如何保障业务持续发展？是否需要重新做架构？

而且，当我们面临诸多业务需求时，也对系统的计算、存储能力提出了更高要求，扩展性便成为支撑复杂业务场景的基本盘。

其次，许多系统解决的往往是某个领域的问题，并将其做到极致。但企业面临的问题是多种多样的，因此，一体化架构必须具备应对多种业务负载的能力。

第三就是如何把一体化架构用好。我们做了很多对已有系统的兼容，帮助企业顺利地迁移原有业务系统，使其更方便、更快地融入一体化架构。

一体化架构需要支持更多的数据模式、使用场景。在新时代，我们应该开发新的系统，还是在解决需求的同时，沿着一体化思路往前迈一步，满足企业在新的大模型驱动下对数据底座的要求？

这个问题，OceanBase 的答案是持续打磨一体化产品。这个产品，不是一天就建成的。

在 2010 年 OceanBase 创立之后，我们花了六七年的时间，解决蚂蚁集团和阿里集团内部核心系统分布式升级的问题。同样，也花了很长时间，在 1.0 版本下迭代了很多数据库该有的基本功能。

后来，我们进入 2.0 时代，开始“走出去”，开展外部客户核心系统替换。3.0 时代，演进出更多对于工作负载的支持。因为我们发现，很多企业做数据基础设施选型时，面临很多技术上的挑战，比如要选择不同场景该用什么系统。

基于更具包容性的架构和更强大的基础，我们能支持更多样化的数据处理需求。数据不仅仅停留在存储和简单查询层面，而且还能实现深入分析和高效检索。正因为如此，OceanBase 步入了 3.0 时代，有效解决了相关的数据挑战。

4.0 时代，我们的目标是如何将一体化架构进一步完善，形成成熟的体系，解决产品的易用性、可复制性问题。在推广过程中，针对企业的研发、运维人员对产品高质量的要求，我们在 4.0 版本的基础上，继续提升产品能力，不仅支持大模型所需的结构化数据存储能力，还具备基于向量和全文的数据检索，与企业原有结构化数据紧密结合，实现更强大的检索和分析能力。

过去 15 年的发展，使我们能够走到现在，并向大家展示 OceanBase 如今的强大能力。我们也在解决企业问题的过程中，一步步以实际问题为驱动，走到了现在。

一体化架构的重要体现

在 OceanBase 一体化架构下，我列了五个重要的发展方向。

第一个是可扩展性。

先说分布式，因为 OceanBase 的标签就是分布式数据库。分布式技术，最早追溯到 20 世纪 80 年代，当时已有大量的学术论文探讨分布式技术。

但 OceanBase 在做分布式数据库时，并不是简单地搭建分布式中间件或分布式架构，而是将分布式技术深度集成到数据库内部，着重解决存储以及在执行层面，如何利用分布式技术，充分发挥多台服务器的硬件能力。

目前，OceanBase 的分布式技术已经很成熟了，在实际生产环境中，我们能够支持单一业务使用数百台机器，实现超过 PB 级数据量的数据库应用，稳定服务于企业的关键生产系统。

此外，OceanBase 分布式能力的强大，掩盖了它在单机上依然可以提供非常好的集中式数据库的服务能力，这里我分享两个关键技术点。

第一点是在 SQL 引擎方面，我们支持执行计划管理。企业在实际应用中常常遇到这样的问题：SQL 在 99.9% 的时间里都运行良好，但由于数据模型或应用压力的变化，偶尔会出现跳变。

为了解决这一难题，我们与众多客户共同打磨出了 SQL 执行计划管理机制。当系统检测到同一 SQL 可能发生执行计划变化时，我们内部会采用基于流量演进的方式，确保新的 SQL 执行计划优于原计划后，才把全部流量切换到新计划上，保证其在实际生产系统中，不会出现因计划突变带来的业务被放大的影响。

第二点是 OceanBase 的强大事务处理能力。熟悉 MySQL 的用户可能知道，虽然 MySQL 对事务大小没有明确限制，但在执行超大事务时，常常会遇到同步麻烦、延迟等问题。如果此时发生容灾，切换过程也会因此受到影响。实际上，不仅是 OceanBase，其他数据库也存在事务大小影响容灾切换流程的问题。

OceanBase 在数据库内核层面解决了这一问题。我们可以执行任意大小的事务，且即使事务正在执行中发生容灾切换，切换时间也不会受当前执行事务规模的影响。

我们承诺的 RPO 为 0，RTO 小于 8 秒，无论在任何情况下都能实现，即使正在执行超大事务，新激活数据库都能在 8 秒内恢复服务。事务回滚将在后台延迟完成，不会影响前台业务的正常运行。

这一能力在单机集中式运营时，是完整寄存的。单机版同样具备高性能和丰富的功能，充分支持企业业务。这就是 OceanBase 单机分布式一体化可扩展架构能带给企业的帮助。

一个核心业务或许是因为业务流量和压力选择了分布式，压力较小的其他系统，依然可以选择 OceanBase 单机版。如今，单机版甚至可以在个人笔记本上轻松运行，仅需极少资源即可提供丰富的数据库功能。

对于企业来说，即使是流量较小的业务，也可以通过简单的资源轻松支持。选择 OceanBase，无论是核心系统还是周边系统，都能在各种业务场景下实现高效运行与成本优化，是企业提升应用效能和经济性的理想选择。

说到兼容性能力，目前 OceanBase 基本支持 MySQL 所有的功能和 Oracle 主流的功能。实现的思路也不是简单地把不同的系统粘合在一起，而是打造了统一的底层存储能力、事务处理能力和 Oracle 优化器、执行器能力。在这一基础上，用 MySQL 或 Oracle 原本的语法，输出这些能力。

也就是说，无论是在 MySQL 兼容模式还是 Oracle 兼容模式下，包括执行计划管理和大事务处理等功能，我们都能够为用户提供同等强大的数据库能力。

为了做好这件事情，前期我们做了非常多细致的工作，因为我们没有使用MySQL等开源代码，而是选择在自己数据库内核做开放接口兼容。为了让兼容的使用方式跟使用原生的 MySQL、Oracle 保持一致，我们做了大量的细节工作。

比如 MySQL 对一类数据做排序时，谁排在前面，谁排在后面，跟 Oracle 做排序时，两个系统的处理方式是不一样的。我们打造了引擎之后，分别做了排序的选择定义。所以针对 Oracle 或 MySQL 兼容模式，两者体验还是不同的。

为支持企业里的应用迁移到 OceanBase，我们除了打造数据库内核之外，还打造了整套生态系统。与 OceanBase 是不是兼容，兼容度有多少，我们有一个 OMA 评估系统，会抓取原始数据库系统里的流量进行分析，看它用到的功能在 OceanBase 里是否提供支持，从而自动生成一个兼容性报表，帮助评估系统迁移的工作量复杂度。

此外，OMS 系统，可以抓取原始数据库全量和实时增量同步的数据流，把其他系统迁移到 OceanBase 上，同时还可以建设反向链路，做更好的数据牵引。

下一个我想分享的是工作负载的一体化，因为很多解决方案中，会把 TP，也就是在线事务处理和 AP 数据分析用不同的系统来实现，但归根结底数据库本身产品设计里面没有那么严格的边界，本质上是技术的呈现。

比如 TP 更注重事务处理能力和简单数据查询、分析链路的性能。而在分析场景中，最新的分析引擎会用到更多先进技术，如针对复杂 SQL 的优化器优化能力，以及能否通过多台服务器协同加速执行计划的执行器能力。

此外，还有向量化执行、加速数据处理速度，以及底层存储引擎是否能帮助数据分析更快的存储格式，这些能力共同构成了现代数据库的核心竞争力。

OceanBase 在发展过程中，已经构建了强大的 SQL 引擎，以及优化器和执行器能力。当我们需要支持更多样化的工作负载时，OceanBase 不是打造新系统扩大产品矩阵，而是专注在现有引擎基础上不断拓展和增强其能力。

我们之所以要做执行计划管理，是因为相较功能简单的数据库，OceanBase 能支持的 SQL 功能，以及能生成执行计划的复杂程度是超过简单系统的。当一个功能更强大的数据库 SQL 引擎能解决更多功能的同时，还会引入 SQL 本身执行计划的膨胀，所以我们比别的系统更有动力去做好执行计划管理这件事，因为 OceanBase 走得更快，支持得更多。

在分析工作负载的场景下，OceanBase 延续了刚才那条路，支持并行执行，即在一台机器的多个 CPU 核心上对同一条 SQL 做加速计算，以及在多台服务器上利用多台服务器核心对同一条 SQL 做加速计算。

同时，我们研发了新的存储引擎，在列存基础上增加很多功能，使数据分析更加高效。随着系统整体性能提升，其实不太需要区分工作负载，不同业务可以在一体化架构下运行。

我们也在这一过程中解决了很多资源隔离的需求问题，运行的东西越来越多，肯定希望对运行的工作负载进行分级，希望它的核心业务不要影响非核心业务，所以在系统内部，我们支持各种层面的资源隔离，对 CPU、I/O 能力的资源进行管控。

在新的业务场景下，OceanBase 已经支持了向量等新的数据类型。这其实是对存储引擎和计算引擎的自然延展，无需额外搭建新的系统，只需在现有系统中增加相应功能并开发新的数据访问接口，就能轻松满足这些需求。同时，用户还能继续享受系统原有的分布式分析和多种兼容模式能力。这样的持续创新，使系统不断叠加新能力，为业务带来更加顺畅和高效的工具体验。

在支持数据格式存储之后，OceanBase 还支持了向量的存储，因为 AI 大模型的驱动，我们着力打造了向量融合的一体化架构。由于用户对文本的非结构化检索需求增多，为了支持好检索的能力，我们做了自研向量内存的索引，自研基于硬盘存储的索引。

从性能来说，OceanBase 已经超过了业内知名向量数据库；从功能而言，我们还可以支持更多的对于向量的检索性能诉求、功能诉求，以及和已有的标量数据联合检索的诉求。

最近一年，我们还在云上着力打造了一个新的存算分离版本。公有云上，计算和存储资源底层逻辑发生了显著的变化，不同于线下，公有云的计算资源是按需申请的，因为这里有本地的块存储、成本最低的对象存储，所以这里的存储供给更丰富。OceanBase 新的能力是，让数据库运行在对象存储上，并提供一个更加极致的低成本存储选择，也就是数据库也是可以运行在对象存储上。

一体化的典型应用场景

很多客户、企业会遇到这样一个问题，公司内部的业务很复杂，如果每一个业务用不同的系统，会带来很多数据的孤岛问题。但 OceanBase 一体化产品，在达到同样安全水平的情况下，可以支撑一个企业主流场景的绝大部分业务诉求，在降低开发难度、运维复杂度，减少资源重复建设、数据重复存储，以及在体系化能力上，一体化数据库可以更好地满足业务企业对于数据底座的诉求。

下面展示的是三个具体的应用场景。

相较于独立的系统，OceanBase 一体化产品有所不同：当向量使用需求出现时，我们会把大量的对于文本检索的诉求放在向量上，因为它带来更多语义的信息。在实际业务中，我们会遇到要检索的文本数据不单纯只有文本，还附加了很多复杂的其他信息，那些信息存储在已有的数据库系统里。

当业务系统想利用不同的信息去做检索时，比如要查一个带了文本检索的、“距离近”的咖啡馆，且评分在 4.5 分以上，以及评价中提及“品质比较好、体验比较好、不会排队”等内容。开发应用时如果涉及不同的系统，最大的挑战就是这个系统里查出的数据不一定满足另外一个数据的需求，到底应该先查评分，还是先去向量数据库里检索评论？

OceanBase 一体化产品，可以通过不同能力的融合，在一条 SQL 里把这些东西描述出来。应该先检索向量，还是先检索原本数据评分，由数据库的优化器决定。我们做出一个根据选择率更优的执行计划之后，把这些问题放在数据库里更优地解决，这就是能给业务的最大价值，也是数据库一体化架构自然的延伸。

当我们支持了多模态、多场景的能力后，我们甚至可以在一个数据库里基于 TP 数据，用增量刷新能力完成原本只有数据仓库才能做到的数据加工，直接生成数据报表。

我们不需要在原有系统上搭建新的系统，就能解决好 TP 数据层层加工的诉求。只需定义 SQL 和新的表，在原来的基础数据库应该用什么样的 SQL 描述，由数据库增量刷新的处理逻辑就能自动推着基于原始的数据汇集、加工出我们最终需要的报表。所以在报表、营销等场景，都可以直接基于一个数据库完成，充分发挥一体化架构的价值。

还有一类场景许多企业会遇到，就是存储在系统里的数据重要程度不同，而且存储的大量历史数据其实是不会被访问的。

基于新的共享存储的分层存储的能力，OceanBase 一体化架构不再需要把数据迁移到其他系统里做冷存储，只需要在系统里定义好数据的冷热分层界限，系统就会自动帮助客户把冷的数据放在更低成本的存储介质上，热的数据放在速度更快的本地缓存上，可以把数据的生命周期管理能力放在系统里。

OceanBase 始终坚持一体化产品理念，随着企业业务不断发展，需求和挑战也在持续增加，相比于使用多个系统各自应对，一体化产品能够支持更多业务场景，为企业应对未来技术挑战和智能化需求提供高性价比的底层支撑。

我的分享到这里，谢谢。

想了解更多资讯

扫码关注👇

了解更多考试相关

扫码添加上智启元官方客服微信👇