同方智慧能源：OceanBase助力构建安全可靠、高性能的能源数据底座

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接即可获取完整内容。
作者：丁泽斌，同方智慧能源数据库工程师
引言

同方智慧能源集团是同方股份有限公司旗下的骨干企业，致力于成为全球领先的综合智慧能源解决方案提供商。公司依托中核集团和清华大学的科技优势，面向建筑、交通、工业、北方供热、数据中心等主要用能场景，提供设计咨询、产品技术、投资建设、运营服务等服务项目，为城市提供绿色低碳能源结构下的智能、节能和能源利用一站式解决方案，提供一流的能源投资运营服务。
本文从业务困境入手，阐述同方智慧在同型数据库产品的对比测试下最终采用OceanBase 4.2.1版本的原因。同时，展示了我们在真实环境中的实践经验，并通过应用案例来说明在业务场景中获得了哪些技术性能的提升和降本增效的收益。
一、业务困境下急需性能强劲的国产数据库

目前，公司项目主要具有以下几个显著特点：

• toG（Goverment，政府）业务。我们的主要项目不同于常见的面向消费者（toC）或企业（toB）的服务，更多的是为政府的工业建设、城市交通、基础设施等提供服务。
  
• 项目独立。项目多拥有完全独立的服务器资源，一般项目间不共享。
  
• 较少使用公有云。极少数项目会使用公有云或相关服务，大规模集群通常会通过内部的私有云或物理机进行部署。
  
• 设备为主体。大多数项目是以设备为主体，能够24小时不间断工作，没有操作极限和压力低谷时期，数据产生频率高。
  

在上述业务背景下，传统数据库由于技术架构老旧、服务器配置低、功能复杂等问题出现了支持瓶颈。一方面，对于物理机来说，MySQL增加单机CPU、内存和存储等方式也难以实现扩展，同时存在单节点出现故障的风险；另一方面，MySQL 的性能提升有限，分库分表方案会增加架构复杂度和改造成本。
图1呈现了公司某项目示例：该项目共采用了14台机器，其中2台配置较低，12台高配。底层架构方面采用了Hadoop，上层则利用Apache Phoenix接口和SQL层转换。在数据传输层面，通过MQ和其他协议进行中间数据传输，同时使用Spark进行离线计算任务。

图1 公司某项目数据库架构示例
该项目构建了一个分布式数据传输系统，将各省的设备数据传输到各自场站，再由场站将数据传输到中心系统。目前，项目涵盖100多个场站，超过350万数据量，每日场站数据量达到10亿条。该项目运行两年，数据规模约为55TB，预计未来将支持2000个场站，6000万点位。尽管目前接入场站和预计支持数据量还存在差距，但庞大的数据量使我们必须提前规划支持方案。
可以看出，在此项目中原有的Hadoop体系组件繁多、搭建复杂、运维成本较高。此外，特殊的Phoenix语法及时序问题给开发人员带来困扰，而性能也无法完全满足我们的要求。
还有一些旧项目采用传统的关系型数据库，运行年代较为久远，技术架构较落后，但功能较复杂，改造成本依然较高。
而对于新项目开发之前可以规划采购服务器的配置和数量，从头开发也不会受到旧代码架构的限制。但对新项目会提出更高的要求，特别是高可靠性和这两年企业非常重视的国产化。
从这些诉求来看，我们希望找到一款数据库产品，具有性能强劲，生态完整，高度兼容传统关系库，同时具备高扩展、高可靠、易于运维等特点的国产自主可控的数据库。
二、多款产品对比下，为什么选择了OceanBase？

在数据库方案选型时，我们研究了适用于不同方向的数据库产品，包括HBase-Phoenix、Apache Ignite、TiDB、OceanBase等，下面是一些基本的调研结果。
1.HBase-Phoenix。

HBase属于KV存储型数据库，Phoenix提供SQL接口，更方便分析和业务开发。但是它的结构较为复杂，不支持多种开源工具，而且默认特性也不符合我们的开发习惯，这使得在实际应用中存在一定的限制。
2.Apache Ignite。

它是一个关系型内存库，我们使用时Ignite它还不够成熟，资料相对较少，社区的活跃度较低。我们遇到了一些问题，例如偶然出现分区丢失导致无法进行表查询，有时正常运行的服务在无业务压力时意外挂掉等，这对于线上数据库来说是无法接受的。
3.TiDB。

根据我们的调研，该产品最低的生产环境要求13台服务器，对于公司的一些老项目来说很难达到这个资源配置水平，因此在实际应用中存在一定挑战。
4.OceanBase。

相较之下，OceanBase由蚂蚁集团完全自研，满足了我们的国产自研需求。其社区活跃度高，官方人员会及时响应用户问题，且生态完善便于运维。值得一提的是，OceanBase高度兼容MySQL。经测试后发现，MySQL项目迁移到OceanBase可以直接运行，应用零改造。此外，OceanBase的流行度也非常高，在墨天轮国产数据库榜位列第一， GitHub Star数量也达到7000+，这些都表明了其在业界的广泛认可和使用(截至2025-03-18，Star数已9K+)。
在国产自研、MySQL兼容度、生态完善等基础上，我们认为OceanBase相比于测试的其他数据库更为优秀，也更加符合我们的实际业务需求。主要体现在以下方面：

• 高扩展性。横向、纵向灵活扩展，自动负载均衡，可根据需求轻松、便捷地扩展节点数量，最多可达1500+节点，且应用无感知；
  
• 高可靠性。数据强一致，集群多副本，支持跨地域容灾，避免单点故障；
  
• 低成本。一体化架构，高压缩比，3台服务器完成最小部署；
  
• HTAP。功能融合，一套引擎同时支持OLTP业务和OLAP业务；
  
• 多租户。资源划分合理，最大化利用资源。
  

最终，我们选择了OceanBase作为新的数据库方案。如图2所示，相较于MySQL等传统数据库，OceanBase得益于架构优势可轻松通过灵活的扩展，优雅地避免单节点故障，同时提高数据库服务的整体性能。由于OceanBase兼容MySQL，因此，我们无需过多担心应用改造的问题和成本。

图2 传统数据库与OceanBase的架构比较
同时，我们对OceanBase和MySQL进行了性能压测对比，图3是我们测试 OceanBase 4.2.1版本和MySQL 8.0版本得出的数据。测试基于32核、64G内存、200G磁盘的机器进行，并将Sysbench 1.0.2 作为性能压测工具，操作系统使用的是Anolis 8.8。

图3 OceanBase 4.2.1版本和MySQL 8.0版本测试数据对比
在这样的环境下，我们分别对“100万单表”和“100万10张表”进行了测试，并考虑了不同线程数下OceanBase和MySQL的性能表现。可以看到，MySQL在32 线程之后性能逐渐下降。OceanBase在多线程下性能持续提升，同等硬件环境下性能达到MySQL 8.0的2倍。通过这次测试可以看出，OceanBase在相同硬件环境下具有更好的性能表现，尤其在多线程下表现更为突出，相较于MySQL 8.0的性能提升明显。这进一步证实了我们选择OceanBase作为数据库解决方案的正确性和可靠性。
三、应用OceanBase后易用性显著提升

经过多个版本的测试后，我们最终使用了OceanBase 4.2.1版本，版本间最显著的提升是易用性，特别是OCP和 OBD均支持白屏，避免了复杂配置，这让我们开启了OceanBase的部署工作。 在搭建过程中，我们发现OceanBase与CentOS 7.9的适配最佳，但为了适应国产化需求，更倾向于使用Anolis 8.8。以下是我们在真实环境中的实践经验，供大家参考。
（一）资源配置

因为OceanBase是以租户为单位划分CPU和内存资源，即使只搭建实例，自身也会占用一定的CPU和内存资源。虽然从OceanBase 4.0版本开始可以在低配置、低资源环境下运行，但我们不建议在实际生产环境中过低地配置资源，否则实际资源可能会分配不足。
（二）磁盘选择

目前OceanBase建议使用SSD磁盘，不建议使用机械硬盘。对于一些在测试环境中使用硬盘的公司会带来一定的影响，可能会导致效率低下，影响使用效果。在规划磁盘的时候，无论数据量再少，日志磁盘规划都应该至少是内存的三倍，否则OCP默认无法将所有内存资源分配给租户。为了防止I/O资源竞争，日志盘、数据盘、系统盘最好独立配置，不要共用。
（三）搭建方式选择

OBD和OCP各有优势，OBD非常便捷，自带OCP Express，也可以对集群进行简单的管理，不需要集群资源过多的配置规划即可完成集群的搭建。但一些高级操作需要在终端操作命令行来完成，比如无法直接通过页面管理 OBProxy，也无法对集群进行重启等，因此对维护人员要求较高。相较而言，OCP功能强大且更便于维护。在OCP下，可以完成多种高级操作，同时支持管理多个集群，非常适合大型项目的搭建。不过，OCP作为独立的组件，需要较高的资源配置，而且在搭建OCP时，需要至少一台独立机器以及建设独立的OceanBase集群以提升其稳定性，确保功能不受限制，这些都限制了OCP在中小项目上的应用。
近来，我们发现新版本的OBD可以直接部署OCP，这表明OBD和OCP等工具正在逐步成熟和更加便利。除了OCP和OBD外，我们还使用了OMS、ODC、CDC、OBKV、OAT等导出工具和迁移评估工具，以及MySQL生态工具。我们建议官方将OBD、OCP和OAT合并，或更加凸显各自的侧重点，更好地提升用户体验感，这样的整合将使用户更方便地管理和维护数据库，同时减少学习和使用成本。
四、应用场景：采用OceanBase 的技术项目改造

（一）场景1：某新能源项目

该项目已接入20个下属省级分公司100多个新能源发电场站，数据点位超过350万，业务覆盖几乎全国各省。通过构建分布式数据传输系统，实现设备数据经场站汇聚至中心系统的传输架构。当前系统运行两年已积累55TB数据，日均处理数据达10亿条。根据规划，未来将扩展至支持2000个场站及6000万点位规模。
原项目采用Hadoop体系物理机搭建，其中nn节点2台：内存192G 48核，磁盘约3T，dn节点12台：内存384G 96核 1T×2+8.7T磁盘，加上其他服务器总共约20台服务器，整个技术架构庞大且繁杂，技术门槛高，运维成本高。
我们决定使用OceanBase对项目进行改造，首先从集控中心级别进行改造，我们为OceanBase准备了1个ocp节点与6台observer节点，配置如表1所示。
表1 OceanBase配置

6台observer节点均部署了obproxy服务，为了提高性能，我们使用lvs对6台服务器上的obproxy做了负载均衡，结构如图4所示。

图4 公司新能源项目OceanBase集群结构
改造后的集群易于维护，有完整的生态组件，利用OCP可以对集群进行可视化管理与监控，对MySQL超高的兼容性让开发人员学习成本极低，以及高可用的分布式结构保证的数据可靠性，这些都是传统的技术架构不易实现的。
我们从该项目的应用中看到了国产数据库的更多可能性，内部也在积极地将OceanBase推广到各个项目。我们对OceanBase仍然有些许期望：可能有些项目现状已经形成，特别是在改造初期，可能没有条件去投入采购新的服务器，希望能改进低配服务器特别是无固态服务器的运行效率。
（二）场景2：某省会城市新地铁线路项目

某省会城市新开通地铁线路，承载着高效运营与数字化管理的核心任务。在车站运营、设备监控、运维管理等场景中，需处理海量数据的实时存储、查询与分析。为满足业务对数据管理的高可靠性、高扩展性需求，该线路引入OceanBase数据库，构建起稳定高效的数据底座，支撑全线路业务的流畅运转。
线路运营涉及设备状态监测数据，以及运维中故障和报警数据，数据规模随运营时长持续增长，对数据库的存储与处理能力提出严苛挑战。
该项目之所以选择OceanBase，是因为如下特性：

• 强大的分布式能力。OceanBase 支持水平扩展，能无缝应对地铁业务数据量的爆发式增长，确保系统性能不随数据增加而下降。
  
• 高可用性保障。地铁运营系统不容许中断，OceanBase 的多副本机制、自动故障切换能力，可实现数据库服务的高可用，保障票务、监控等关键系统 7×24小时稳定运行。
  
• 兼容性与易用性。兼容MySQL语法，与地铁既有业务系统对接成本低，开发团队能快速上手，减少系统迁移与改造难度。
  

该项目在改造前后的服务器配置见表2。
表2 项目改造前后的服务器配置

使用OceanBase前，采用传统关系型数据库架构，服务器集群规模固定，面对数据激增时，扩展难度大、成本高，且存在单点故障风险。使用OceanBase后以分布式架构为核心，仅需相对精简的服务器集群配置，即可通过横向扩展轻松应对数据增长。其弹性计算资源分配机制，让服务器资源利用更高效，无需大规模硬件投入即可满足业务需求。
同时，项目经过OceanBase改造后，稳定性大幅增强。上线至今，未因数据库层面问题导致业务中断。面对设备监控数据的高频写入、复杂查询场景，OceanBase 始终保持稳定运行，为地铁设备的实时运维提供了坚实支撑。运维效率优化主要体现在OceanBase的自动化运维特性提升上，如自动扩容、故障自愈等，大幅减少运维团队工作量。以往需要人工干预的复杂操作，如今系统可自动完成，运维效率提升超20%。
尽管OceanBase已在该线路展现卓越价值，未来仍可进一步探索其潜力：例如深入挖掘OceanBase在实时数据分析场景的特性，结合地铁客流规律，优化运营调度策略；加强对技术团队的OceanBase高级特性培训，让数据库能力与业务创新更深度融合。相信随着技术的持续迭代，OceanBase将为更多轨道交通线路，创造更高效、更智能的数据管理体验，持续引领智慧地铁建设的新高度。
五、未来计划：扩展OceanBase业务范围

OceanBase是一个可扩展、高可用、高性能的原生分布式数据库系统，具备强大的数据处理能力，能够支持各种业务场景的需求。未来，我们计划将OceanBase 应用到更广泛的业务范围，主要从以下四个方面展开。
（1）业务类型。扩大从业务数据到实时数据，再到系统的实时数据和历史数据的范围，以更好地满足不同业务场景的需求，提高数据处理效率。
（2）业务范围。从集控中心走向多层级协同集群，更好地支持大规模业务场景，提高系统的可靠性和其他性能。
（3）集群规模。从高配置的小型集群走向高配置的大型集群，并逐步演变为多集群规模，更好地满足大规模数据处理和可伸缩性需求。
（4）业务方向。以新能源项目为切入点，逐步将OceanBase应用在供热供暖、地铁交通、智慧建筑等行业，可以更好地支持这些行业的数字化转型和创新发展。
在图5中，目前我们仅仅在集控中心级别使用了OceanBase，我们希望随着OceanBase的发展，可以更便捷的将多个层级的不同集群的OceanBase数据进行融合同步，最终实现多集群、多业务类型上数据库的统一，并逐步将OceanBase推广至其他项目。

图5 新能源领域应用展望
此外，我们非常看好OceanBase OBKV的NoSQL能力，以打造更为全面的一体化数据库。我们对OceanBase的未来充满信心，期待OceanBase能为我们带来更高的性能、更低的成本和更好的收益，为公司的业务发展提供更强大的支持。

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！