本文作者：丁泽斌，同方智慧能源数据库工程师
业务背景
作为同方股份有限公司旗下的领军企业，同方智慧能源集团矢志成为全球领先的综合智慧能源解决方案提供商。凭借中核集团和清华大学的科技实力，专注于向建筑、交通、工业、北方供热、数据中心等核心用能领域，提供全方位的服务，包括设计咨询、产品技术、投资建设以及运营维护。为城市构建绿色低碳的能源结构，提供智能、节能及能源利用的一站式解决方案，并提供卓越的能源投资运营服务。目前，公司项目主要有以下主要特色：
○ ToG 业务：我们的主要项目不同于常见的 面向消费者（toC） 或 企业（toB）的服务，更多的是为政府的工业建设、城市交通、基础设施等提供服务。
○ 项目独立：项目多拥有完全独立的服务器资源，资源一般不共享。
○ 较少使用公有云：极少数项目会使用公有云机器或服务，大规模集群通常会通过内部的私有云或物理机进行部署。
○ 设备为主体：大多数项目是以设备为主体，能够 24 小时不间断工作，没有操作极限和压力低谷时期，数据产生频率高。
一、业务中面临的数据库困境
在上述业务背景下，传统数据库由于技术架构老旧、服务器配置低、功能复杂等问题出现了支持瓶颈。一方面，对于物理机来说，MySQL 增加单机 CPU、内存和存储等方式也难以实现扩展，同时存在单节点故障的风险。另一方面，MySQL 的性能提升有限，分库分表方案会增加架构复杂度和改造成本。
我们公司的某项目示例如下：共有 14 台机器，包括 2 两台配置较低的机器和 12 台高配的机器。在底层架构方面，我们采用了 Hadoop，上层利用 Apache Phoenix 接口和 SQL 层转换、数据传输层面，通过 MQ 和其他协议进行中间数据传输，同时使用 Spark 进行离线计算任务。
该项目构建了一个分布式数据传输系统，将各省的设备数据传输到各自场站，再由场站将数据传输到中心系统。目前，项目涵盖 100 多个场站，超过 350 万数据量，每日场站数据量达到 10 亿条。该项目运行两年，数据约 55TB，预计未来将支持 2000 个场站，6000 万点位。尽管目前接入场站和预计支持数据量还存在差距，但庞大的数据量使我们必须提前规划支持方案。
在此项目中，Hadoop 体系组件繁多，搭建复杂，运维成本较高。此外，特殊的 Phoenix 语法及时序问题给开发人员带来了困扰，而性能也无法完全满足我们的要求。新项目不受限于服务器的性能，可以提前规划配置与数量，不会被已有代码所限制，从业务诉求角度，我们希望在该项目采用国产自研数据库技术。
因此，我们希望选择一款满足业务要求，性能强劲、生态完整、MySQL，强兼容、具备高扩展、高可靠、易于运维的数据库作为新的解决方案。
二、为什么选择 OceanBase
在数据库方案选型时，我们研究了适用于不同方向的国产数据库，篇幅有限下面主要介绍对 HBase-Phoenix、Apache Ignite、TiDB、OceanBase 的调研结果。
○ HBase-Phoenix：HBase 属于 KV 存储型数据库，Phoenix 将其变成提供 SQL 的接口，更方便分析和业务开发。但是它的结构较为复杂，不支持多种开源工具，而且默认特性也不符合我们的开发习惯，这使得在实际应用中存在一定的限制。
○ Apache Ignite：它是一个关系型内容库，但其资源相对较少，社区的活跃度较低。在初次使用 Apache Ignite 时，我们遇到了一些问题，例如偶然出现分区丢失导致无法进行表查询，正常运行的服务意外挂掉等，这对于线上数据库来说是无法接受的。
○ TiDB：根据我们调研最低的生产环境要求 13 台服务器，对于公司的一些老项目来说，很难达到这个资源配置水平，因此在实际应用中存在一定的挑战。
○ OceanBase：相较之下，OceanBase 由蚂蚁集团完全自研，满足了我们的国产自研需求。其社区活跃度高，官方人员会及时响应用户问题，且生态完善便于运维。值得一提的是，OceanBase 高度兼容 MySQL。经测试后发现，MySQL 项目迁移到OceanBase可以直接运行，应用零改造。此外 OceanBase 的流行度高也非常高，墨天轮国产数据库榜位列第一，GitHub Star 数量也达到 7000+，这些都表明了其在业界的广泛认可和使用。
在国产自研、MySQL 兼容度、生态完善等基础上，我们认为 OceanBase 相比于测试的其他数据库相比更为优秀，也更加符合我们的实际业务需求。主要体现在以下方面：
○ 高扩展性：横向、纵向灵活扩展自动负载均衡，可根据需求轻松灵活地扩展节点数量，最多可达 1500+ 节点，且应用无感知；
○ 高可靠性：数据强一致，集群多副本，支持跨地域容灾，避免单点故障；
○ 低成本：一体化架构，高压缩比，3 台服务器完成最小部署；
○ HTAP：一套引擎支持 OLTP 业务和 OLAP 业务；
○ 多租户：资源划分合理，最大化利用资源。
同时，我们针对性能对 OceanBase 和 MySQL 进行了压测对比。下图是我们测试 OceanBase 4.2.1 版本和 MySQL 8.0 版本得出的数据。我们使用了 32 核、64G 内存、200G 磁盘的机器进行测试，并将 Sysbench 1.0.2 作为性能压测工具，操作系统使用 Anolis 8.8。
在这样的环境下，我们分别对 100 万单表和 100 万 10 张表进行了测试，并考虑了不同线程数下 OceanBase 和 MySQL 的性能表现。可以看到 MySQL 在 32 线程之后，性能逐渐下降。OceanBase 在多线程下性能持续提升，同等硬件环境下性能达到 MySQL 8.0 的 2 倍。通过这次测试可以看出，OceanBase 在相同硬件环境下具有更好的性能表现，尤其在多线程下表现更为突出，相较于 MySQL 8.0 的性能提升明显。这进一步证实了我们选择 OceanBase 作为数据库解决方案的正确性和可靠性。
三、同方能源应用 OceanBase 的实践经验和收益
我们从 OceanBase 3.1.3 版本开始研究，并经历了多个版本的测试，直到最终使用 OceanBase 4.2.1 版本，我们发现在易用性方面得到极大提升，特别是 OCP 和 OBD 均支持白屏，避免了复杂配置，这让我们开始了 OceanBase 的部署工作。
在搭建过程中，我们发现 OceanBase 与 CentOS 7.9 的适配最佳，但为了适应国产自研需求，我们更倾向于使用 Anolis 8.8。以下是我们在真实环境的经验，供大家参考。
○ 资源配置：因为 OceanBase 是以租户为单位划分 CPU 和内存资源，即使只搭建实例，自身也会占用一定的 CPU 和内存资源。虽然 从 OceanBase4.0 版本开始可以在低配置低资源环境下运行，但我们不建议在实际生产环境过低地配置资源，否则实际资源可能会分配不足。
○ 磁盘选择：目前 OceanBase 建议使用 SSD 磁盘，不建议使用机械硬盘。对于一些在测试环境中使用硬盘的公司会带来一定的影响，可能会导致效率低下，影响使用效果。在规划磁盘的时候，日志磁盘无论数据量再少，磁盘规划应该至少是内存的三倍，否则 OCP 默认无法将所有内存资源分配给租户。为了防止 I/O 资源竞争，日志盘、数据盘、系统盘最好分别独立，不要共用。
○ 搭建方式选择：OBD 和 OCP 各有优势，OBD 非常便捷，自带 OCP Express，也可以对集群进行简单的管理，不需要集群资源过多的配置规划，即可完成集群的搭建。但一些高级操作需要在终端操作命令行来完成，比如无法直接通过页面管理 OBProxy ，也无法对集群进行重启等，因此对维护人员要求较高。OCP 功能强大、更方便维护。OCP 可以完成多种高级操作，同时支持管理多个集群。非常适合大型项目的搭建。不过，OCP 作为独立的组件，如果分配过多资源，会造成不必要的资源浪费。而且在搭建 OCP 时，需要一台独立机器以及建设独立的集群以提升其稳定性，确保功能不受限制。
近期我们发现新版本的 OBD 可以直接部署 OCP，这表明 OBD 和 OCP 等工具正在变得越来越成熟和便利。除了 OCP 和 OBD 外，我们还使用了 OMS、ODC、CDC、OBKV、OAT、导出工具、迁移评估工具，以及 MySQL 生态工具。我们建议官方将 OBD、OCP 和 OAT 合并，或更加凸显各自的侧重点，更好地提升用户体验感。这样的整合将使用户更方便地管理和维护数据库，同时减少了学习和使用成本。
四、规划未来
OceanBase 是一个可扩展、高可用、高性能的原生分布式数据库系统，具备强大的数据处理能力，能够支持各种业务场景的需求。未来，我们计划将 OceanBase 应用到更广泛的业务范围，主要从四个方面展开：
○ 在业务类型方面，扩大从业务数据到实时数据、再到系统的实时数据和历史数据的范围，以更好地满足不同业务场景的需求，提高数据处理效率。
○ 在业务范围方面，从集控中心使用走向多层级协同集群，更好地支持大规模业务场景，提高系统的可靠性和性能。
○ 在集群规模方面，从高配置的小型集群走向高配置的大型集群，并逐步演变为多集群规模，更好地满足大规模数据处理和可伸缩性需求。
○ 在业务方向方面，以新能源项目为切入点，逐步将 OceanBase 应用在供热供暖、地铁交通、智慧建筑等行业，可以更好地支持这些行业的数字化转型和创新发展。
此外，我们非常期待 OceanBase OBKV 集成 NoSQL 能力，以打造更为全面的一体化数据库。我们对 OceanBase 的未来充满信心，期待 OceanBase 能为我们带来更高的性能、更低的成本、更好的收益，为公司的业务发展提供更强大的支持。