“让技术被看见 | OceanBase 布道师计划”由 OceanBase 主办，CSDN 协办，面向广大开发者的年度征文活动。全年 4 轮，以季度为周期进行优秀文章评比，每年 1 届，以年为单位进行最佳布道师评选。
目前，首轮技术征文获奖文章已评选出炉，本篇内容为「OceanBase 布道师计划」优秀文章之一，作者为邱永刚。
评委有话说
封仲淹（OceanBase 开源生态总监、OceanBase 开源社区负责人）：这篇文章从用户非常关心的一个问题着手，如何降本增效，如何充分利用历史硬件，使用混闪磁盘（ssd + 机械盘）来降低成本，并通过大量的测试来验证其可行性，有很强的说服能力以及非常贴合用户比较关心的问题。
老鱼（资深 IT 媒体人、《老鱼笔记》主理人）：文章记录了从纯SSD到混闪机型的部署转变过程，通过详尽的测试验证和实际案例分析，展示了OceanBase在不同存储配置下的性能表现与稳定性。文中还探讨了如何在保证业务稳定性的前提下降低成本、充分利用存量资源的问题，实践意义很强。
目前生产环境OceanBase数据库集群部署一般要求磁盘类型为SSD存储，OceanBase的存储高压缩比，大大节省了磁盘存储空间，但面对海量历史归档库等场景，仍存在存储不够用、计算资源浪费等问题。本文探讨了混闪机型（事务日志盘采用纯SSD，数据盘采用机械硬盘）的可行性，通过详尽的验证过程，得出不同规格、不同场景下混闪机型相对纯闪机型的性能损耗及稳定性表现。同时结合生产环境的实际应用案例，为海量数据场景下部署OceanBase提供了参考。在满足业务稳定性、性能要求的前提下，使用混闪机型进行部署，可大大降低硬件资源使用量、解决纯闪机型资源不足、存量资源无法使用等问题。
背景
OceanBase 数据库的存储引擎基于 LSM-Tree 架构，基线数据存磁盘，增量数据直接写内存。当内存的增量数据达到一定阀值时，会触发增量数据落盘（转储），同时每天晚上的空闲时刻，系统也会自动进行全局动静数据的归并，生成基线数据（合并）。通过这种准内存的增量数据处理，可以大大提升增量数据增删改的性能。另外，由于基线数据是只读的，可以采用比较激进的压缩算法，在不损失查询性能的条件下，可以做到很高的压缩比。为了保证数据的持久性，在增量数据写内存的同时会将redo_log落盘并同步给从副本，满足多数派成功落盘的情况下事务才是成功的，同时转储合并也会有集中的磁盘IO操作，为了保证数据库的高性能，OceanBase官方会要求使用SSD存储来部署集群。
根据我们的理解，使用SSD存储主要是为了提高性能，有一些应用对性能要求并不高，所以我们之前也部署了一些机械盘的集群。在运行一段时间之后，陆续出现了一些clog不同步、集群不稳定，甚至于集群瘫痪的问题，为此我们也及时进行了固态盘的替换，但我们也一直没有停止对机械盘部署的探索。在看到OceanBase官网发表的《数据库历史库，成本与性能不可以兼得吗？》文章后，我们了解到使用机械盘来部署OceanBase也是可行的，于是我们也及时与文章作者进行了沟通，了解到了详细的使用场景与部署方式，得知对数据实时性要求较高的事务日志使用固态盘部署，数据盘使用机械盘部署的方案是可行的，于是，我们对这种混闪机型部署方式进行了验证。以下是详细验证过程。
验证说明：
本次测试验证主要针对全闪机型与混闪机型进行对比
全闪机型：磁盘全部为SSD
混闪机型：事务日志盘为SSD（本次测试为NVME），数据盘为HDD
数据库版本：4.2.1.1
测试验证资源：
全闪机型：
麒麟ARM*3：国产化产品（ARM）:CPU32core*2/内存512G/硬盘SATASSD960G*12
混闪机型：
麒麟ARM*3：国产化产品（ARM）:CPU32core*2/内存512G/硬盘NVME1.8T*2+SATAHDD8T*12
验证场景1：批量入库
结论：批量入库场景下，性能随规格线性增长，32c64G规格后，性能增长趋缓，混闪机型比全闪机型性能下降约29%。
验证场景2：普通入库
结论：普通入库场景下，性能随规格线性增长，32c64G规格后，性能增长趋缓，混闪机型比全闪机型性能下降约26%。
验证场景3：普通只读
结论：普通只读场景下，性能随规格线性增长，32c64G规格后，性能增长趋缓，混闪机型比全闪机型性能下降约6%。
验证场景4：普通读写
结论：普通读写场景下，性能随规格线性增长，32c64G规格后，性能增长趋缓，混闪机型比全闪机型性能下降约12%。
验证场景5：TP综合测试tpcc
结论：综合事务TPCC测试，混闪机型比全闪机型性能下降约14%。
验证场景6：稳定性测试
使用sysbench进行压力测试，设置并发度为300，在普通读写场景下，数据库可以稳定运行72小时。
验证结论：
通过对不同规格下各场景测试，混闪机型在入库场景下比全闪机型性能下降约28%，只读场景性能下降约6%，综合读写性能下降约13%。
在稳定性方面，通过72小时sysbench高并发持续读写，数据库稳定运行无异常。但当前测试无法模拟实际生产环境复杂场景，OceanBase库在真实生产环境复杂场景下可能更易出现转储合并异常问题，影响集群稳定。
混闪机型用高性能的NVME或SSD来存储需实时落盘的事务日志，用HDD来存储数据量较大的业务数据，适用于对性能要求不高、业务相对简单、数据量较大的历史库、日志库、备份库等场景。
通过测试验证，混闪机型相比纯闪机型，会有20%左右的性能下降，稳定性方面也没有发现有直接的影响，这个结果极大的鼓舞了我们，因为我们有大量历史库、日志库场景，数据量庞大，但在线业务较少，对性能、计算资源要求不高。为此，我们即时进行了混闪机型替代，针对日志库场景，有业务一天的日志量在近20亿条，增量数据考虑多副本在4T左右，存储1个月数据需要纯闪机型机器30台。进行混闪机型替代后，只需要3台机器即可满足需求，一下子节省机器27台，仅这一个场景便节省硬件投资近300万元。另一方面，存量资源池存在大量机械盘主机，这样这些存量资源得以利用，避免了出现大量资源浪费的情况。
总结
经过对混闪机型（即事务日志盘采用纯固态硬盘SSD，数据盘采用机械硬盘HDD）在性能与稳定性方面的严格测试与验证，结果显示，相较于纯闪机型，混闪机型在性能上约有20%的降幅，但在OceanBase4.x版本上能够保持持续且稳定的运行。混闪机型特别适合于那些对性能要求不苛刻、业务逻辑相对简单但数据量庞大的应用场景，诸如历史库、日志库、备份库等。通过实际生产环境的验证，其可行性得到了充分证实。
鉴于普通机型机械硬盘相较于固态硬盘在存储容量上通常高出一个数量级，混闪机型在这些特定场景下能够显著降低约90%的硬件成本。这一优势不仅大幅削减了硬件投入，还显著提升了资源利用率。以电信运营商的日志库为例，电信业务涉及大量且多元化的用户接入，除BOSS核心系统外，还会有手机营业厅、网上营业厅、各级子系统以及代理商等，通过服务调用日志分析，可以为业务运营提供宝贵的决策支持。采用混闪存储方案，在减少硬件成本的同时，还能提供更长时间的数据存储，进而为运营决策提供更加精准的数据支撑。
此外，混闪机型的引入打破了纯闪机型在OceanBase数据库部署上的单一限制。在当前信创替代加速、IT技术日新月异的背景下，大大缩短了IT设备的更新换代周期，许多被替换下来的设备，其使用寿命往往远未达到6-8年的报废周期，弃之可惜。而这些设备虽然计算能力可能不是最优，但拥有高容量的机械硬盘。通过混闪部署OceanBase的方式，这些旧设备的利用价值得到了显著提升。同时，对于一些大公司而言，其设备采购往往涵盖多种机型，混闪机型的部署方式不仅拓宽了OceanBase在部署场景上的适用范围，还为多样化的应用场景提供了更加灵活、经济且高效的解决方案。
