利用混闪机型部署 OceanBase 集群的探索与实践
本文作者：联通研究院 邱永刚
目前生产环境 OceanBase 数据库集群部署一般要求磁盘类型为 SSD 存储，OB 的存储高压缩比，大大节省了磁盘存储空间，但面对海量历史归档库等场景，仍存在存储不够用、计算资源浪费等问题。本文探讨了混闪机型（事务日志盘采用纯 SSD，数据盘采用机械硬盘）的可行性，通过详尽的验证过程，得出不同规格、不同场景下混闪机型相对纯闪机型的性能损耗及稳定性表现。同时结合生产环境的实际应用案例，为海量数据场景下部署 OceanBase 提供了参考。
在满足业务稳定性、性能要求的前提下，使用混闪机型进行部署，可大大降低硬件资源使用量、解决纯闪机型资源不足、存量资源无法使用等问题。
背景
OceanBase 数据库的存储引擎基于 LSM-Tree 架构，基线数据存磁盘，增量数据直接写内存。当内存的增量数据达到一定阀值时，会触发增量数据落盘（转储），同时每天晚上的空闲时刻，系统也会自动进行全局动静数据的归并，生成基线数据（合并）。通过这种准内存的增量数据处理，可以大大提升增量数据增删改的性能。另外，由于基线数据是只读的，可以采用比较激进的压缩算法，在不损失查询性能的条件下，可以做到很高的压缩比。为了保证数据的持久性，在增量数据写内存的同时会将 redo_log 落盘并同步给从副本，满足多数派成功落盘的情况下事务才是成功的，同时转储合并也会有集中的磁盘 IO 操作，为了保证数据库的高性能，OB 官方会要求使用 SSD 存储来部署集群。
根据我们的理解，使用 SSD 存储主要是为了提高性能，有一些应用对性能要求并不高，所以我们之前也部署了一些机械盘的集群。在运行一段时间之后，陆续出现了一些 clog 不同步、集群不稳定，甚至于集群瘫痪的问题，为此我们也及时进行了固态盘的替换，但我们也一直没有停止对机械盘部署的探索。在看到 OB 官网发表的《数据库历史库，成本与性能不可以兼得吗？》文章后，我们了解到使用机械盘来部署 OB 也是可行的，于是我们也及时与文章作者进行了沟通，了解到了详细的使用场景与部署方式，得知对数据实时性要求较高的事务日志使用固态盘部署，数据盘使用机械盘部署的方案是可行的，于是，我们对这种混闪机型部署方式进行了验证。以下是详细验证过程。
验证说明：
本次测试验证主要针对全闪机型与混闪机型进行对比
全闪机型：磁盘全部为 SSD
混闪机型：事务日志盘为 SSD（本次测试为 NVME），数据盘为 HDD
数据库版本：4.2.1.1
测试验证资源：
全闪机型：
麒麟 ARM * 3：国产化产品（ARM）:CPU 32 core * 2 / 内存 512G / 硬盘 SATA SSD 960G * 12
混闪机型：
麒麟 ARM * 3：国产化产品（ARM）:CPU 32 core * 2 / 内存 512G / 硬盘 NVME 1.8T * 2 + SATA HDD 8T * 12
验证场景1：批量入库
| 8c16G | 16c32G | 32c64G | 64c128G | |
|---|---|---|---|---|
| 全闪 | 54903 | 85870 | 178158 | 221443 |
| 混闪 | 38622 | 61772 | 121918 | 164340 |
结论：批量入库场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 29%。
验证场景2：普通入库
| 8c16G | 16c32G | 32c64G | 64c128G | |
|---|---|---|---|---|
| 全闪 | 24490 | 48079 | 87440 | 91702 |
| 混闪 | 20513 | 40768 | 56511 | 56352 |
结论：普通入库场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 26%。
验证场景3：普通只读
| 8c16G | 16c32G | 32c64G | 64c128G | |
|---|---|---|---|---|
| 全闪 | 57283 | 106498 | 173308 | 198595 |
| 混闪 | 53010 | 96702 | 166397 | 188010 |
结论：普通只读场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 6%。
验证场景4：普通读写
| 8c16G | 16c32G | 32c64G | 64c128G | |
|---|---|---|---|---|
| 全闪读 | 36029 | 69911 | 131861 | 148802 |
| 全闪写 | 1801 | 3495 | 6593 | 7440 |
| 混闪读 | 34102 | 61301 | 111449 | 125255 |
| 混闪写 | 1705 | 3065 | 5572 | 6262 |
结论：普通读写场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 12%。
验证场景5：TP综合测试tpcc
| 8c16G | 16c32G | 32c64G | 64c128G | |
|---|---|---|---|---|
| 全闪 | 35127 | 82656 | 137854 | 158995 |
| 混闪 | 28042 | 67327 | 118766 | 157774 |
结论：综合事务 TPCC 测试，混闪机型比全闪机型性能下降约 14%。
验证场景6：稳定性测试
使用 sysbench 进行压力测试，设置并发度为 300，在普通读写场景下，数据库可以稳定运行 72 小时。
验证结论：
-
通过对不同规格下各场景测试，混闪机型在入库场景下比全闪机型性能下降约 28%，只读场景性能下降约 6%，综合读写性能下降约 13%。
-
在稳定性方面，通过 72 小时 sysbench 高并发持续读写，数据库稳定运行无异常。但当前测试无法模拟实际生产环境复杂场景，OB 库在真实生产环境复杂场景下可能更易出现转储合并异常问题，影响集群稳定。
-
混闪机型用高性能的 NVME 或 SSD 来存储需实时落盘的事务日志，用 HDD 来存储数据量较大的业务数据，适用于对性能要求不高、业务相对简单、数据量较大的历史库、日志库、备份库等场景。
通过测试验证，混闪机型相比纯闪机型，会有 20% 左右的性能下降，稳定性方面也没有发现有直接的影响，这个结果极大的鼓舞了我们，因为我们有大量历史库、日志库场景，数据量庞大，但在线业务较少，对性能、计 算资源要求不高。为此，我们即时进行了混闪机型替代，针对日志库场景，有业务一天的日志量在近 20 亿条，增量数据考虑多副本在 4T 左右，存储 1 个月数据需要纯闪机型机器 30 台。进行混闪机型替代后，只需要 3 台机器即可满足需求，一下子节省机器 27 台，仅这一个场景便节省硬件投资近 300 万元。另一方面，存量资源池存在大量机械盘主机，这样这些存量资源得以利用，避免了出现大量资源浪费的情况。
总结
经过对混闪机型（即事务日志盘采用纯固态硬盘 SSD，数据盘采用机械硬盘 HDD）在性能与稳定性方面的严格测试与验证，结果显示，相较于纯闪机型，混闪机型在性能上约有 20% 的降幅，但在 OB 4.x 版本上能够保持持续且稳定的运行。混闪机型特别适合于那些对性能要求不苛刻、业务逻辑相对简单但数据量庞大的应用场景，诸如历史库、日志库、备份库等。通过实际生产环境的验证，其可行性得到了充分证实。
鉴于普通机型机械硬盘相较于固态硬盘在存储容量上通常高出一个数量级，混闪机型在这些特定场景下能够显著降低约 90% 的硬件成本。这一优势不仅大幅削减了硬件投入，还显著提升了资源利用率。以电信运营商的日志库为例，电信业务涉及大量且多元化的用户接入，除 BOSS 核心系统外，还会有手机营业厅、网上营业厅、各级子系统以及代理商等，通过服务调用日志分析，可以为业务运营提供宝贵的决策支持。采用混闪存储方案，在减少硬件成本的同时，还能提供更长时间的数据存储，进而为运营决策提供更加精准的数据支撑。
此外，混闪机型的引入 打破了纯闪机型在 OceanBase 数据库部署上的单一限制。在当前信创替代加速、IT 技术日新月异的背景下，大大缩短了 IT 设备的更新换代周期，许多被替换下来的设备，其使用寿命往往远未达到 6 ~ 8 年的报废周期，弃之可惜。而这些设备虽然计算能力可能不是最优，但拥有高容量的机械硬盘。通过混闪部署 OceanBase 的方式，这些旧设备的利用价值得到了显著提升。同时，对于一些大公司而言，其设备采购往往涵盖多种机型，混闪机型的部署方式不仅拓宽了 OceanBase 在部署场景上的适用范围，还为多样化的应用场景提供了更加灵活、经济且高效的解决方案。