———– 以下为投稿正文 ———–
OceanBase数据库的存储引擎基于LSM-Tree架构，基线数据存磁盘，增量数据直接写内存。当内存的增量数据达到一定阀值时，会触发增量数据落盘（转储），同时每天晚上的空闲时刻，系统也会自动进行全局动静数据的归并，生成基线数据（合并）。通过这种准内存的增量数据处理，可以大大提升增量数据增删改的性能。另外，由于基线数据是只读的，可以采用比较激进的压缩算法，在不损失查询性能的条件下，可以做到很高的压缩比。为了保证数据的持久性，在增量数据写内存的同时会将redo_log落盘并同步给从副本，满足多数派成功落盘的情况下事务才是成功的，同时转储合并也会有集中的磁盘IO操作，为了保证数据库的高性能，OceanBase官方会要求使用SSD存储来部署集群。
根据我们的理解，使用SSD存储主要是为了提高性能，有一些应用对性能要求并不高，所以我们之前也部署了一些机械盘的集群。在运行一段时间之后，陆续出现了一些clog不同步、集群不稳定，甚至于集群瘫痪的问题，为此我们也及时进行了固态盘的替换，但我们也一直没有停止对机械盘部署的探索。在看到OceanBase官网发表的《数据库历史库，成本与性能不可以兼得吗？》（https://open.oceanbase.com/blog/12198675456）文章后，我们了解到使用机械盘来部署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：批量入库
| 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高并发持续读写，数据库稳定运行无异常。但当前测试无法模拟实际生产环境复杂场景，OceanBase库在真实生产环境复杂场景下可能更易出现转储合并异常问题，影响集群稳定。
混闪机型用高性能的NVME或SSD来存储需实时落盘的事务日志，用HDD来存储数据量较大的业务数据，适用于对性能要求不高、业务相对简单、数据量较大的历史库、日志库、备份库等场景。
02
总结
经过对混闪机型（即事务日志盘采用纯固态硬盘SSD，数据盘采用机械硬盘HDD）在性能与稳定性方面的严格测试与验证，结果显示，相较于纯闪机型，混闪机型在性能上约有20%的降幅，但在OceanBase4.x版本上能够保持持续且稳定的运行。混闪机型特别适合于那些对性能要求不苛刻、业务逻辑相对简单但数据量庞大的应用场景，诸如历史库、日志库、备份库等。通过实际生产环境的验证，其可行性得到了充分证实。
鉴于普通机型机械硬盘相较于固态硬盘在存储容量上通常高出一个数量级，混闪机型在这些特定场景下能够显著降低约90%的硬件成本。这一优势不仅大幅削减了硬件投入，还显著提升了资源利用率。以电信运营商的日志库为例，电信业务涉及大量且多元化的用户接入，除BOSS核心系统外，还会有手机营业厅、网上营业厅、各级子系统以及代理商等，通过服务调用日志分析，可以为业务运营提供宝贵的决策支持。采用混闪存储方案，在减少硬件成本的同时，还能提供更长时间的数据存储，进而为运营决策提供更加精准的数据支撑。
此外，混闪机型的引入打破了纯闪机型在OceanBase数据库部署上的单一限制。在当前信创替代加速、IT技术日新月异的背景下，大大缩短了IT设备的更新换代周期，许多被替换下来的设备，其使用寿命往往远未达到6-8年的报废周期，弃之可惜。而这些设备虽然计算能力可能不是最优，但拥有高容量的机械硬盘。通过混闪部署OceanBase的方式，这些旧设备的利用价值得到了显著提升。同时，对于一些大公司而言，其设备采购往往涵盖多种机型，混闪机型的部署方式不仅拓宽了OceanBase在部署场景上的适用范围，还为多样化的应用场景提供了更加灵活、经济且高效的解决方案。
- END -
IT168与ITPUB技术社区强强联手，收集数百款主流数据库产品，重磅推出“数据库全景图”，旨在打造一款集知识普及、产品对比、选型参考于一体的综合性资源平台。“数据库全景图（11月版）”可扫描上方左侧二维码回复关键词获取，识别右侧二维码直达“数据库全景图”链接（右上角浏览器打开获取更好体验）。
