作者：丁泽斌，同方智慧能源数据库工程师
同方智慧能源集团是同方股份有限公司旗下的骨干企业，致力于成为全球领先的综合智慧能源解决方案提供商。依托中核集团、 清华大学的科技优势，面向建筑、交通、工业、北方供热、数据中心等主要用能场景，提供设计咨询、产品技术、投资建设、运营服务，为城市提供绿色低碳能源结构下的智能、节能和能源利用一站式解决方案，提供一流的能源投资运营服务。目前，公司项目主要具有以下几个显著特点：
○ 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 能为我们带来更高的性能、更低的成本、更好的收益，为公司的业务发展提供更强大的支持。
