当前位置：首页 > news >正文

对比分析 OceanBase 与数据库中间件

news 2025/7/30 20:54:21

* 本文转载于OceanBase博客博主，作者为AntTech_OK0J0W。本文观点仅代表作者观点。

一、核心观点

1.1 架构差异

OceanBase 是一种原生分布式数据库，其架构设计、底层存储机制以及查询处理方式均专门针对分布式数据管理的需求而优化。与之对比，数据库中间件的工作原理通常是将数据分拆并存储在不同的数据库点上，借助中间件来实现统一管理和访问散布于各节点的数据，这种方式的本质在于将集中式数据库与分布式中间件相结合，因此在架构层面并未实现彻底的分布式化。OceanBase 具备高可用性和高扩展性，能够根据需要灵活增加节点，且节点的数量不受限制，所有节点在功能上均保持对等，读写性能随着节点数量的增多而线性提升。采用 Shared-Nothing 的技术架构，可实现机架级、机房级、城市级容灾。例如，OceanBase 能够通过 “两地三中心” 甚至 “三地五中心” 的方式帮助金融机构应对容灾挑战。

1.2 应用场景，各有所长

对于业务模型简单的互联网交易场景，数据库中间件架构的分布式一度受到欢迎。但随着业务的发展，其缺陷逐渐显现，增加了应用层的复杂度和应用事务中间件等。而金融行业业务模型复杂度高且对数据一致性要求远高于互联网，OceanBase 这样的原生分布式数据库更具优势。在金融行业的交易处理、风控系统等场景中，OceanBase 通过高效的事务处理和数据一致性保证，能够满足高性能和高可靠性的需求。数据库中间件则可能更适用于一些对数据一致性要求不那么严格、业务相对简单的场景。

1.3 未来趋势，融合创新

未来，OceanBase 与数据库中间件有望走向融合创新。随着数据量的不断增长和业务需求的不断变化，单一的技术解决方案可能难以满足企业的全部需求。OceanBase 可以借鉴数据库中间件在某些方面的灵活性，而数据库中间件也可以吸收 OceanBase 在高可用、高扩展和数据一致性方面的优势。通过融合创新，为企业提供更加完善的数据管理解决方案，助力企业在数字化时代更好地应对各种挑战。

二、OceanBase 与数据库中间件对比分析

2.1 架构特点对比

2.1.1 OceanBase 的原生分布式架构

OceanBase 的原生分布式架构设计理念是为了满足日益增长的数据处理需求，尤其是在金融、电商等对数据库性能、稳定性和扩展性有极高要求的行业。其优势在于高可用、高扩展，各个节点对等，读写性能随节点数量增加呈线性增长。例如，在金融交易系统中，OceanBase 能够通过分布式架构和优化的执行引擎，提供高性能的读写操作和毫秒级的延迟响应。其应用场景广泛，适用于各种需要高性能、高可靠性和高扩展性的业务场景，如金融交易系统、大数据分析平台和云计算环境等。

2.1.2 数据库中间件架构

数据库中间件架构通常是将数据分拆到不同的数据库节点上，利用中间件来管理和访问各个数据库中的数据。其工作原理是通过中间件对底层数据库进行统一管理和调度。然而，这种架构存在一定的局限性。例如，只适用于简单业务，同时对业务有侵入性，需要改造；很难支持跨分片的高性能复杂查询；分布式事务性能损失较大；水平扩展能力差，只能按照选定的分片规则横向扩展；大型集群运维困难，表结构变更操作困难，只能按照分片进行维护等。

2.2 性能表现对比

2.2.1 OceanBase 的高性能优势

OceanBase 在性能方面表现突出。在单机性能方面，通过自研的一体化架构，融合事务和 KV，在不牺牲单机性能的前提下实现可扩展性，可有效支撑核心业务场景。在分布式事务处理上，采用新一代分布式处理技术，颠覆传统数据库集中式技术架构，通过分布式扩展集群实现扩展能力的大幅提升，并通过分布式选举技术、事务技术充分保证业务场景的一致性，实现整体性能的数量级提升。例如，在 TPC-C 基准测试中，OceanBase 打破了由美国公司 Oracle 保持了 9 年之久的世界记录，性能分数首次突破亿级大关达到 7.07 亿 tpmC，相比去年的成绩提升近 11 倍。

2.2.2 数据库中间件的性能特点

数据库中间件在性能上有一定的优势与不足。优势方面，架构相对简单，单机事务延迟低，应用充分适配后可以在位置原有延迟低基础上获得 TPS 的线性提升，对底层的关系型数据库改动不大，运维经验可以复用。但不足之处也很明显，如只适用于简单业务，很难支持跨分片的高性能复杂查询，分布式事务性能损失较大，水平扩展能力差，主从数据同步延迟问题等。

2.3 用户使用门槛对比

2.2.1 OceanBase 的低门槛优势

OceanBase 实现 “一个公司只需要一个数据库”，降低了用户使用门槛。OceanBase 数据库集群作为一个整体对外提供服务，用户无需关注集群内部的实现细节。其坚持 100% 自主研发，从头开始打造原生分布式数据库，把复杂留给数据库，把简单留给客户。例如，在安装部署方面，OceanBase 4.1 版本推出了向导式的安装部署，让部署时间从小时级降到分钟级，可实现 2 分钟部署 demo 环境、10 分钟完成标准部署集群。同时，将开发工具（OCP Express）集成到社区版，一键下载全部署，解决管理困难问题。

2.2.2 数据库中间件的高门槛挑战

数据库中间件在用户参与数据分拆和节点管理方面存在较大难度。通常需要用户参与到数据分拆和节点管理过程中，分库分表、中间件统一调度是高难度的技术操作，这会极大地提升用户的使用门槛。例如，在水平拆分和垂直拆分过程中，需要进行 sql 解析、路由、改写、执行和结果集合并等复杂操作，同时还需要解决分布式 id、分布式事务、动态扩容等问题，这些都增加了用户使用的难度。

三、OceanBase 的应用案例分析

3.1 电商领域应用

在电商领域，以淘宝网为例，随着电商业务的飞速发展，数据量呈爆炸式增长，交易峰值不断刷新纪录。OceanBase 在此场景中发挥了重要作用。它解决了高并发交易下的数据处理难题，确保在购物高峰时段，如 “双十一” 等大型促销活动期间，系统能够稳定应对海量的订单生成、支付处理和库存管理等操作。通过分布式架构，OceanBase 实现了数据的快速读写和高效存储，极大地提高了交易处理速度。在 “双十一” 期间，OceanBase 能够承受每秒数百万的订单创建和支付请求，确保交易的实时性和准确性。同时，OceanBase 的高可用性保证了即使在部分节点出现故障的情况下，系统依然能够稳定运行，不影响用户的购物体验。这为淘宝网带来了巨大的效益，不仅提高了用户满意度，还提升了平台的竞争力，为电商业务的持续增长提供了坚实的技术支撑。

3.2 金融领域应用

在金融机构中，OceanBase 表现出色。例如，在应对容灾挑战方面，OceanBase 能够通过 “两地三中心” 甚至 “三地五中心” 的架构，为金融机构提供强大的容灾能力。以交通银行为例，继贷记卡核心系统分布式改造之后，ECIF、借记卡主机核心、传统账务系统，全国各省分行数据库系统已经全部升级至 OceanBase，计划在 2027 年前完成全行数据库的分布式升级，实现数字化转型。目前其对私核心分布式新核心系统已服务 2.3 亿客户，每秒交易笔数 3 万笔。民生银行对公领域关键业务系统同样使用 OceanBase 进行分布式系统升级，保证行内业务连续性稳定运行，满足金融级高可用要求。此外，OceanBase 还在保险、证券等领域广泛应用，如 70% 的头部保险、75% 的头部证券机构已选择 OceanBase 进行核心系统升级。OceanBase 的高数据一致性、高稳定性和高性能，为金融机构的核心业务提供了可靠保障。

3.3 其他行业应用

在零售领域，多点 DMALL 作为亚洲最大的零售云服务商，选择上线 OceanBase 来更好地支撑业务发展。OceanBase 的性能优势使得多点 DMALL 能够同时兼具单机低延时、分布式高吞吐特性，单机事务占比可以达到 80% 以上。通过 Table group 优化跨机 join 后，单机事务占比可以进一步提升。同时，OceanBase 的高压缩比存储引擎，使集群存储空间相比 MySQL 节省 75%，成本更低。其多租户和资源隔离能力也很好地解决了 SaaS 场景需要部署一套系统，想要节省成本且方便后期扩容的需求。

在运营商领域，OceanBase 已承载中移动 1/3 省级核心系统，服务全国 60% 移动用户。例如，OceanBase 已成功服务于江苏、浙江、河南、山东等 11 个中国移动省级分公司，涵盖近 20 个核心业务系统及 300 余个实例。河南移动在 2023 年 10 月选定了 OceanBase 进行升级改造，仅用 2 个月时间就完成了一套承载 1500 万用户的核心系统升级，SQL 执行性能整体提升 35%，数据库集群的平均资源利用率提升至 12%-20%。山东移动全业务核心系统平稳运行逾千日，成本显著下降，存储成本节省 90%；江苏移动 CRM 及 BOSS 系统硬件成本缩减 80%；福建移动多个运营核心系统完成升级，实现 RPO=0 的机房级灾难恢复，容灾响应时间从小时级缩短至秒级。

在公用事业领域，如智慧公交领域，雄帝科技在 2020 年智慧交通产品在 SaaS 化转型中同步进行技术创新升级，业务系统的后台支持部署至国产服务器上运行，操作系统也兼容麒麟等国产主流操作系统，并在公交支付业务上切换到国产数据库 OceanBase。OceanBase 的分布式架构，首推 “三地五中心” 城市级容灾新标准，具有高可用、高数据压缩比、多副本产品架构等特点，能较好解决在公交支付复杂应用场景中遇到的问题。随着数智化时代的来临，OceanBase 作为分布式数据库，大有成为数智时代基础底座的趋势，为公用事业的智能化建设提供了有力支持。

四、数据库中间件的应用案例分析

4.1 分库分表架构应用

京东作为电商巨头，其业务量庞大，数据增长迅速。数据库中间件在京东自营数据库中发挥了重要作用。

在数据分片方面，京东采用了多种分库分表策略。例如，对于商品信息数据，可以根据商品类别进行水平分片，将不同类别的商品数据存储在不同的数据库中。同时，对于订单数据，可以根据时间范围进行水平拆分，当某个时间范围内业务数据过大时，可以将这部分数据根据特定规则进行二次均匀拆分。这样的分库分表策略有效地降低了单个数据库的存储压力，提高了数据存储和查询的效率。

读写分离功能也是京东数据库中间件的重要应用之一。京东为数据库搭建了灾备副本，将生产及灾备库分为主库、从库两种角色。主库处理所有的修改、变更操作以及少部分读操作，从库分担主库大部分的读请求。通过这种方式，有效地缓解了数据库的访问压力，提高了系统的性能。

以京东的商品查询服务为例，当用户查询商品信息时，数据库中间件会根据查询请求自动路由到相应的分库中进行查询。如果查询请求涉及多个分库，中间件会将查询结果进行合并后返回给用户。同时，对于频繁更新的商品库存信息，中间件会确保主库和从库之间的数据同步，保证数据的一致性。

京东云 DRDS 是京东精心自研的数据库中间件产品，可实现海量数据下的自动分库分表。它具有高性能、分布式、弹性升级、兼容 MySQL 等优点，适用于高并发、大规模数据的在线交易，历史数据查询，自动数据分片等业务场景。2 节点即可支持数万 QPS，满足用户超大规模处理能力的需求。

4.2 跨库事务处理应用

数据库中间件在跨库分布式事务处理中面临着诸多挑战。其中，数据一致性问题是最为关键的挑战之一。在分库分表的情况下，数据可能被拆分到不同的数据库实例或表中，这就会导致数据一致性难以维护。

为了解决跨库事务处理中的数据一致性问题，京东采用了多种解决方案。一方面，通过分布式事务协调器来实现跨库事务一致性。例如，使用 TCC、XA 等分布式事务协调器，确保在跨多个数据库进行事务处理时，能够保证事务的原子性、一致性、隔离性和持久性（ACID）。另一方面，通过中间件来实现数据的分库分表自动路由，如京东金融分布式数据中间件 CDS，实现了 JDBC 标准 API，支持分库分表、读写分离和数据运维等诸多功能，提供高性能、高并发和高可靠的海量数据路由存取服务。

在跨库事务处理中，事务处理问题也不容忽视。跨库事务处理可能会出现问题，如无法保证整个事务的一致性，可能会出现数据不一致的情况。为了解决这个问题，京东将事务逻辑尽量控制在同一库内，减少跨库事务的发生。同时，使用分布式事务中间件来协调多个数据库之间的事务，如 Seata、TCC-Transaction 等，确保事务的正确处理。

对于分布式事务问题，京东通过将事务拆分为多个独立的子事务，并通过消息队列等异步方式来保证最终一致性。例如，在京东的订单处理系统中，当用户下单后，订单信息会被写入主库，同时通过消息队列将订单信息发送给从库进行异步处理。这样，即使在主库和从库之间出现网络故障等问题，也能够通过消息队列的重试机制保证数据的最终一致性。

五、OceanBase 与数据库中间件的适配情况

5.1 常见数据库中间件与 OceanBase 的适配

Tomcat 与 OceanBase 的适配

OceanBase 数据库的 MySQL 模式可用 MySQL 官方 JDBC 驱动连接，对于使用 Tomcat 中间件的情况，适配方式如下：按照 OceanBase 数据库手册安装部署 OceanBase for MySQL 服务，初始化 OA 的 MySQL 数据库版本。可以通过 OA 安装程序选择 MySQL 数据库脚本，在安装程序中数据库可选择 MySQL，URL 可配置成 OceanBase for MySQL 的地址。然后找到 base/conf 文件夹下的 datasourceCtp.properties 配置文件，修改 db.hibernateDialec 的值为 org.hibernate.dialect.MySQLDialect，修改 workflow.dialect 的值为 MYSQL，修改 ctpDataSource.driverClassName 的值为 com.mysql.jdbc.Driver，修改 ctpDataSource.url 的值为 jdbc:mysql:// 数据 IP: 数据库端口 / 数据库名称（注意这里的 IP 端口一定要对应 OceanBase for MySQL 的地址），填写正确的数据库名称和密码（这里一定是 OceanBase for MySQL 的数据库名称和密码），最后正常启动系统即可。

国产中间件与 OceanBase 的适配

对于使用国产中间件（如东方通、金蝶、宝兰德等）的情况，适配方式如下：按照 OceanBase 数据库手册安装部署 OceanBase for MySQL 服务，初始化 OA 的数据库。可以信创安装包解压获取到初始化 sql 文件，直接在 OceanBase 数据库中执行 sql 脚本。信创部署包中文件所在位置参考：2.V9.0_XinChuang/deploytools/file/sql/init/A8N - 2/MySQL/A8N - 2_ALL_IN_ONE_MYSQL.SQL，注意区分不同产品线和版本。参考对应 OA 版本的信创部署手册，使用信创部署工具部署应用，信创工具部署时数据库选择其他即可。在中间件 jvm 参数配置需要增加驱动代理参数：-Djdbcproxydriver.driverclass=com.mysql.jdbc.Driver。如果使用 mysql 5.* 系列驱动包，则驱动类名为：com.mysql.jdbc.Driver；如果使用 mysql8.* 系列驱动包，则驱动类名为：com.mysql.cj.jdbc.Driver。中间件数据源配置时全部以 mysql 数据库配置，即：数据库厂商选择 mysql，驱动类名使用统一驱动类名：com.seeyon.ctp.monitor.perf.jdbcmonitor.proxyobj.JMProxyDriver。数据源配置时的数据库、ip、用户名、密码等都填写 OceanBase for MySQL 的数据库名称和密码，测试连接正常后再启动 OA 验证功能。

5.2 适配过程中的问题与解决方案

在适配过程中可能会出现一些问题，以下是常见问题及解决方案：

问题一：数据库连接问题

在适配过程中，可能会出现数据库连接失败的情况。这可能是由于配置文件中的 IP 地址、端口号、数据库名称或密码错误导致的。解决方案是仔细检查配置文件中的各项参数，确保其与 OceanBase for MySQL 的实际配置一致。

问题二：驱动类名问题

如果使用不同版本的 mysql 驱动包，可能会出现驱动类名不匹配的问题。解决方案是根据实际使用的驱动包版本，正确设置驱动类名。如果使用 mysql 5.* 系列驱动包，则驱动类名为 com.mysql.jdbc.Driver；如果使用 mysql8.* 系列驱动包，则驱动类名为 com.mysql.cj.jdbc.Driver。

问题三：中间件配置问题

在配置国产中间件时，可能会出现中间件 jvm 参数配置错误或数据源配置错误的问题。解决方案是按照适配方式中的步骤，正确配置中间件 jvm 参数和数据源。增加驱动代理参数 - Djdbcproxydriver.driverclass=com.mysql.jdbc.Driver，并以 mysql 数据库配置数据源，选择正确的数据库厂商和驱动类名，填写正确的数据库、ip、用户名、密码等信息。

六、OceanBase 与数据库中间件的结合使用

6.1 OBProxy 在提升性能中的作用

OBProxy（OceanBase Database Proxy）作为高性能数据访问中间件，在提升 OceanBase 性能方面发挥着重要作用。

链路对性能的影响：引入 OBProxy 后，虽然整体链路上多了一个模块，但对性能影响不大。大部分情况下连接 OBProxy 和连接 OBServer 的性能差距不大，并且因为 OBProxy 转发效率更高，有时性能更好。OBProxy 部署到应用端时性能最好，研发团队还研发了富客户端功能，把 OBProxy 的功能打包成一个 so 动态库，JDBC/C 驱动等加载该 so 就可以使用富客户端能力，无需部署运维 OBProxy，使用非常方便。

扩展性：OBProxy 本身是无状态的，启动速度特别快，可以在 1～2s 内完成启动提供服务。在双十一等高并发场景，OBServer 经常进行机器变更，OBProxy 能感知 OBServer 的副本位置变更操作，在路由时选择正确的 OBServer 为用户提供服务，扩展性非常好。

数据路由：研发团队实现了丰富的路由算法如 LDC 路由、Primary Zone 路由、读写分离路由等。在 OBServer 的新版本，还将要上线事务路由功能，性能会变得更好，能减少 TCP 通信次数，更高效发挥每一台 OBServer 能力，性能提升有 50% 左右。OBProxy 单核性能在 2～4w 之间，云上 16c 测试约有 40w QPS；没有明显性能热点函数，每个函数 CPU 消耗都在 5% 以下；工作线程建议配置和 CPU 核数一样，更多的线程数不会再带来性能提升。对于 OBProxy 使用的协议，性能数据为 MySQL 协议 > 2.0 协议 > 压缩协议，将压缩协议改为 MySQL 协议后性能会带来明显提升。

6.2 结合使用的案例分析

在丽迅物流的上云进程中，他们接触并评估了国内多款分布式数据库，最终选择了 OceanBase 的云数据库（OB Cloud），用以升级其多个关键业务系统。在这个过程中，丽迅物流采用了云数据库 + 中间件的 Proxy 分库分表模式，虽然一开始使用的是更稳定的云数据库 + 中间件 DBLE，但随着功能的不断丰富，对性能也会产生一定的损耗。后来，丽迅物流将目光瞄准了市场上几款成熟的分布式数据库产品，经过多番对比，最终确认了 OB Cloud 云数据库。

丽迅物流仓储管理、财务管理、客户、工单、HR 等多个关键业务系统着手上线 OB Cloud。通过使用两个 30 核 180GB 的分布式节点，替换了 5 组 64 核 128GB 的 MySQL 服务器，上线半年后，原来 5TB 的业务数据压缩到 600GB 左右，业务性能同步提升，至今运行稳定。在财务管理系统中，通过对其进行数据合并迁移，去掉 ShardingJDBC，迁移到一个 14 核 70GB 的集群上，迁移后，该系统业务量占比大量缩减，只需简单调整业务代码，原来一年 2.5TB 的数据可以压缩到 350GB。

此外，在河北移动核心营业系统数据库升级过程中，他们采用了 OceanBase 国产数据库，通过 OBProxy 实现了数据库的高可用和高性能。在迁移工程中，河北移动通过借助集团磐舟能力，有效解决数据库国产过程中应用代码频繁发布难题，代码从上传 - 编译 - 镜像打包，推送到磐基 PaaS 平台，均通过可视化界面进行操作，简单直观。同时搭配流水线配置，实现全过程高效的可持续化自动运行。

这些实际案例展示了 OceanBase 与数据库中间件结合使用的效果，不仅提高了数据库的性能和可用性，还降低了成本，为企业的数字化转型提供了有力支持。

七、风险分析

7.1 技术风险

OceanBase 作为原生分布式数据库，虽然在性能和扩展性方面具有显著优势，但也面临一些技术风险。例如，在兼容性方面，虽然对 MySQL 绝大部分常用用法兼容，但对 Oracle 还只是兼容了标准 SQL 和一些常用函数，传统 Oracle 数据库上复杂的存储过程和 package 在 OceanBase 里运行可能有性能问题。同时，对机器配置要求不低，如至少 32C64G，生产环境建议 256G 等，这对于一些资源有限的用户来说可能是一个挑战。

数据库中间件也存在技术风险。其只适用于简单业务，很难支持跨分片的高性能复杂查询，分布式事务性能损失较大，水平扩展能力差，主从数据同步延迟问题等。此外，在版本升级方面也存在困难，因为应用使用数据源代理就是引入一个 jar 包的依赖，在有多个应用都对某个版本的 jar 包产生依赖时，一旦这个版本有 bug，所有的应用都需要升级。