在这样的存储架构下，OceanBase的数据压缩集中发生在compaction过程中SSTable的写入时，数据的在线更新与压缩得到了解耦。

OceanBase支持不感知数据特征的通用压缩（compression）和感知数据特征并按列进行压缩的数据编码（encoding）。这两种压缩方式是正交的，也就是说可以对一个数据块先进行编码，然后再进行通用压缩，来实现更高的压缩率。

OceanBase批量落盘的特性使其采用更激进的压缩策略，如图5所示。OceanBase是行列混存的微块存储格式（PAX），充分利用了同一列数据的局部性和类型特征，在微块内部对一组行以列存的方式存储，并针对数据特征按列进行编码。变长的数据块和连续批量压缩的数据也可以让OceanBase通过同一个SSTable中已经完成压缩的数据块的先验知识，指导下一个数据块的压缩过程，从而在数据块中压缩尽量多的数据行，并选择更优的编码算法。

图5 OceanBase的压缩策略示意

与部分在schema上指定数据编码的数据库实现不同，OceanBase选择了用户不感知的数据自适应编码，在给用户带来更小负担的同时降低了存储成本。从历史归档库角度而言，我们也不需要针对数据做出过多与压缩和编码相关的配置调整。

（二）数据库选型：高可用和稳定性对比

除存储成本以外，我们还对比了ClickHouse和OceanBase的高可用能力和稳定性。

1.ClickHouse

我们将ClickHouse拟作历史库，对其进行了充分测试：通过Replication（复制）来实现集群中不同服务器之间自动同步数据的功能，以确保数据的高可用性和容错性；使用ZooKeeper来协调复制过程，跟踪所有副本的状态，并确保它们保持一致。Replication和ZooKeeper保证了在不同的物理设备上有多个数据副本，减少了数据丢失的风险。

图6 ClickHouse高可用架构

不过在使用ClickHouse的过程中，我们发现它的高可用方案在大数据量的场景下会存在一些问题。主要由于原生的Replication方案有太多信息存在ZooKeeper上，而为了保证服务，一般会有一个或几个副本。但ZooKeeper不支持线性扩展，受单机服务能力限制，当归档库集群的数据量持续增长时，整个服务很快会不可用。

实际上在ClickHouse使用时，大家往往都把ZooKeeper当成多种服务的结合，而不仅仅把它当作一个Coordinateservice。例如常见做法中，还会把它当作LogService，很多行为日志等数字的信息也会存在ZooKeeper上；还会作为表的catalogservice，表的一些schema信息也会在ZooKeeper上做校验，这就会导致ZooKeeper上接入的数量与数据总量会成线性关系。按照我们归档库的数据增长速度做预估，ClickHouse搭配ZooKeeper无法支撑三到五年全量归档数据需求。

此外，ClickHouse的复制功能高度依赖ZooKeeper。但ZooKeeper是一个外部的协调服务，本身的配置和维护增加了额外的复杂性，且如果ZooKeeper自身出现问题，可能会影响ClickHouse的复制过程。同时，这种高可用方案还增加了问题排查的链路长度和定位问题的难度，恢复过程也变得比较复杂，需要手动干预。我们在使用ClickHouse的过程中很容易出现丢数据的情况。

2.OceanBase

OceanBase是原生的分布式数据库，原生就可以保证多个数据副本之间的一致性，它们利用了基于Paxos的分布式一致性协议保证了在任一时刻，只有当多数派副本达成一致时，才能推选一个Leader，保证主副本的唯一性来对外提供数据服务。也就是说，OceanBase通过多副本和Paxos协议来保证数据库的高可用。

图7 OceanBase高可用架构

相比MySQL和ClickHouse的高可用方案，OceanBase的高可用方案降低了我们的运维难度和业务变更难度。且OceanBase的多地多副本架构和Paxos一致性协议，还能够支持数据副本分别存储在同城和异地，实现异地容灾。

图8 OceanBase多地多副本架构

因为OceanBase具备分布式特性，所以数据存储原生就具备了动态扩容的能力。当归档库的数据量持续增长时，只需要我们的DBA执行几条命令，就可以对机器的硬件或者整个集群的节点数进行扩容。在集群增加新节点之后，数据会自动在新、老节点之间完成负载均衡的过程，可以做到业务无感知的平滑扩容，保证业务扩容时不停机。同时这还节省了业务量猛增后的数据库扩容和迁移成本，极大降低了数据库容量不足造成的各种风险。

对OceanBase进行扩容时，无论是增加单机的容量，还是增加Zone内的节点数，亦或是为了保证更高的可用性而增加新的Zone，都可以直接通过白屏化的OCP工具来完成。图9就是我们把一个单副本的集群扩展成三Zone三副本时的一张OCP截图。

图9 通过OCP将OceanBase单副本集群扩展为三Zone三副本

相较黑屏执行命令的方式，我们的DBA同学反馈使用OCP来进行OceanBase的部署和运维会更加方便，推荐大家使用。

（三）数据库选型小结

综上所述：相比MySQL和ClickHouse，在一致性方面，OceanBase原生就有着强一致的存储保证，而不是去用最终一致性的妥协换取其他方面的能力，而且也不需要通过配置各种复杂的周边组件来保障一致性。在高可用方面，OceanBase的多副本容灾技术面向单个集群，事务日志持久化并在多个副本之间同步日志数据，基于Paxos协议保证日志数据在多数派副本持久化成功，整体上对用户提供了少数派故障时RPO=0，RTO<8s的高可用能力。在整个测试过程中，OceanBase的表现相比MySQL、ClickHouse和DB-U也更加稳定。

综合考量各种数据库的存储成本、高可用能力、运维难度等方面之后，我们最终选择了OceanBase作为我们的历史归档库。

三、OceanBase在BOSS直聘历史归档库业务的落地实践

（一）OceanBase历史归档库架构

我们目前的在线库是主从结构的MySQL，用于存储热数据，一般是最近一个月内的用户聊天记录；历史归档库是几个由OCP接管的OceanBase集群。每个月我们都会通过一个自研的DTS工具，从MySQL在线库定期归档过期数据到通过OceanBase搭建的历史库，整体架构如图10所示。

图10 BOSS直聘在线与历史库的架构示意

至2024年初，我们用OCP接管了8个OceanBase归档业务集群，超过20个租户。在线库MySQL分表超过万张，仍然在源源不断地通过App按照用户的IDhash向MySQL写入数据，过期的历史数据现在会直接新导入到归档库OceanBase中。

图11 OceanBase历史归档库管理界面

我们曾用过的一个旧ClickHouse归档库集群目前仍提供部分历史数据的读取功能，不过考虑到ClickHouse的稳定性和数据安全问题，该归档集群会逐步被OceanBase替换掉。

（二）OceanBase用作归档库的业务收益

首先，OceanBase通过数据库内核的高压缩能力，帮助我们轻松完成冷数据归档，且节省了超过70%的存储资源。

图12 OceanBase高压缩特性示意

其次，OceanBase是原生的分布式系统，有着良好的扩展性，还可以对用户提供少数派故障时RPO=0，RTO<8s的高可用能力，让数据库在使用过程中更加稳定。

最后，OceanBase自带一个智能化的白屏OCP平台工具，降低了我们DBA同学的部署和运维的门槛。OCP对集群，租户，主机，软件包等资源对象进行全生命周期管理，包括管理，安装、运维、性能监控、配置、升级等功能。并且除了默认的监控告警之外，现在OCP还支持自定义告警，比如我们可以定制磁盘、内存使用率的报警阈值，满足了定制化的告警需求。此外OCP还支持备份恢复，且在运维过程中可以支持一些自动化的诊断功能。

图13 OceanBase的OCP白屏工具大大降低了运维难度

四、从非核心业务走向规模化上线：OceanBase在BOSS直聘的落地历程与应用案例

（一）OceanBase在BOSS直聘的落地历程

自2023年末开始对OceanBase进行项目调研以来，OceanBase在BOSS直聘的落地过程经过了四个阶段，分别是调研与适配、非核心业务（前文提到的历史归档库）试点、核心业务接入和业务规模化上线，如图14所示。

图14 OceanBase在BOSS直聘的落地里程碑

调研阶段结束后，项目进入第二阶段，即内部中间件的适配，包括DTS以及读写分离的中间件等，以及归档库的试点。随后，经过在历史归档库业务的试点部署，我们便计划在公司内部大面积接入OceanBase，其中包括一些相对重要的业务场景，如招聘时的聊天场景，其数据量非常庞大（经过一次增加表存储的二级分区改造，打散写入压力后，整体响应时间更平稳）。

业务接入OceanBase后，我们投入了大量工作来应对业务在使用过程中可能遇到的问题。从2024年10月起，我们将重心转移到OceanBase元数据管理和内部管控平台对接，完善内部监控告警体系，提升运维自动化效率与内部运维体验。

图15展现了BOSS直聘内部关系数据库的整体架构布局。前端流量首先由内部代理软件OneDB接收，随后OneDB智能地将流量分发至主或从数据库，确保数据处理的高效与灵活。

图15 BOSS直聘内部关系数据库的整体架构

对于OceanBase的应用，目前我们采取了两种主要策略：归档与数据冷热分离。

归档方式操作简便。如前文所述，我们将日常关联数据库中的部分数据定期归档至OceanBase，实现数据的长期保存与管理。而冷热分离方式则更为精细，我们将最新的一部分数据同时存储在MySQL和OceanBase中。其中，MySQL负责存储最近一段时间内的热数据，确保快速访问；而OceanBase则存储全量数据，包括热数据和冷数据，为数据查询和分析提供全面支持。此外，我们还在系统底层部署了一个日志订阅服务。这一服务的主要职责是将数据实时同步至数据仓库，为后续的数据分析和应用提供有力支撑。

目前，我们已部署20+OceanBase集群，线上节点数100+。所使用的物理机的存储容量分为3T、7T和15T等多种规格，确保每一套集群使用的存储容量一致，以便后续管理。在上线的业务中，可以分为四个主要的应用场景。

• 数据归档场景。我们会定期归档MySQL中的冷数据以释放搜索存储空间。
• 聊天消息处理场景。在这个场景中，我们采用双写机制来存储消息。MySQL中存储最近一个月的数据，而OceanBase中则存储所有数据。
• 分析类场景。它与聊天功能紧密相关。在这个场景中，我们主要存储聊天过程中的行为数据，并对这些数据进行相关分析。
• 该场景涉及我们内部的管控平台，用于存储元数据。目前，我们将cmdb和配置中心的一些元数据存储在OceanBase中。选择其存储的主要原因是，当计算机发生故障时，我们可以利用OceanBase的高可用性来消除切换过程中的循环依赖，确保在机房故障发生时，管理平台能够迅速恢复。

图16 OceanBase在BOSS直聘的四大应用场景

下面以聊天消息处理业务为例，讲述OceanBase在Boss直聘核心业务的应用情况。

（二）OceanBase在BOSS直聘核心业务的应用：聊天消息处理

聊天消息场景的集群有数十个节点，每个节点使用的存储都是单盘15T。机器配置方面，32核和48核配置不等。整体来看，我们的数据增长很快，基本上每个月都会向集群中增加机器，以应对存储容量的增加。在高峰期，写入量可达数万级别的QPS，我们能保证90%的请求在4毫秒左右完成。

我们最初的消息存储按照单分区设计，主要基于时间维度进行分区。这样做导致了一个问题，即某一天的消息都会写入同一个分片，使得主分片在一天中的写入量非常大，从而产生了性能瓶颈。由于写入量过大，在高峰期或某些时间段，业务响应时间会出现波动，导致业务体验较差。

对此，我们的优化策略是在按天分区的基础上，根据ID进行二级哈希分区。这样可以将单点的写入流量分散到多个节点，消除写入瓶颈。同时，我们将单条写操作改为批量处理，减少了应用与数据库的交互次数，降低了网络和IO开销。通过这两种方式，我们一方面消除了单点写入的瓶颈问题，另一方面也解决了响应时间波动的问题。虽然改造后由单条写变为批量写，响应时间有所上升，但上升幅度在可接受范围内，并且抖动问题得到了完美解决。

此外，在使用OceanBase的过程中，我们还进行了其他方面的优化。

其一，当少量Join从MySQL迁移到OceanBase后，性能有所下降。特别是小表之间的关联查询出现了跨节点的情况。为解决这个问题，我们利用了现有的tablegroup机制，将需要关联的表放置在同一个节点上，以避免跨节点的开销。在节点重新均衡后，我们再次测试了产品性能，发现相比迁移前有了显著提升。

其二，频繁更新的小表查询缓慢。这个表的数据量不大，但增删改操作非常频繁，在OceanBase中被称为“Queuing表”。查询缓慢的主要原因是，在删除数据时，OceanBase并不会立即在物理层面删除，导致查询时需要扫描过多的物理行，从而降低性能。为解决这个问题，我们提高了表的转储频率，并迅速清理已删除的记录。这样在查询时就能扫描较少的物理行，从而提高整体性能。

五、成本、效能和稳定性：OceanBase为BOSS直聘带来三重收益

目前，OceanBase已在Boss直聘稳定运行一段时间，在成本、效能和稳定性方面均满足我们的预期。

（一）成本收益

使用OceanBase后，我们的存储成本显著降低，粗略估算至少降低60%。具体来看，一是归档集群，原本4T+的容量，在OceanBase中单副本可达500G左右；压缩率高达8倍；二是聊天消息数据的存储压缩比例在4倍左右，压缩效果令人惊喜。综合来看，使用OceanBase后我们预计能节省50+台物理机，直接降低2025年的硬件采购成本。

（二）效能收益

效能收益体现在两方面，一是查询性能的提升，另一方面是运维效率的提升。

对于查询性能提升，我们最直观的感受是复杂查询的响应时间大幅缩短。同时，从原有系统迁移到OceanBase后，尽管具体数据难以精确计算，但我们能够感受到机器使用率有所降低。

得益于OceanBase的架构优势，其并发处理能力相比传统单机数据库更强。尤其是其灵活扩展的能力，只需将机器加入集群，即可自动扩容。这一能力使我们业务高峰期的弹性扩缩容变得十分方便，直接缩短查询耗时。例如，我们将财务相关查询迁移到OceanBase后，对比迁移前后的平均耗时，发现性能有了显著提升，部分SQL性能提升近20倍，如图17。

图17 财务相关查询迁移到OceanBase后带来的性能提升

另外，OceanBase显著提升了运维效率。引入OceanBase后，线上运维操作变得相对简单。例如，扩缩容过程非常快速，极大地节省了运维人力成本。此外，在排查OceanBase相关问题时，由于OceanBase的工具提供了丰富的监控指标，我们可以依赖这些监控指标快速定位问题。

（三）稳定性收益

使用OceanBase的过程中几乎没有发生稳定性问题（主动运维除外），系统非常健壮。以聊天消息存储场景为例，之前由于表存储为一级分区（时间），存在一定的写入压力，业务在高峰期由于单点瓶颈会存在一定的响应抖动。在改造为二级分区（时间分区的基础上增加了二级hash分区）之后，总体响应时间内再无抖动明显的情况。在运行期间，OceanBase的故障率很低。我们进行了相关宕机演练（宕掉某个节点的情况），其恢复的RTO小于8秒，符合预期。此外，运维操作对业务的影响非常小。

六、未来规划：持续扩大OceanBase的应用范围

由于本次数据库替换项目较为顺利，且取得了多重令人满意的收益，我们计划持续扩大OceanBase的应用范围。具体而言包含几个方面。

第一，对于在线库场景，我们的在线库目前依旧使用MySQL，在MySQL中进行分库分表明显比在分布式数据库中使用单表的业务复杂度要高很多，且数据一致性难以保证，当多个数据表或数据库之间的数据关联较为复杂时，维护数据的一致性难度也会增加很多。在线库的运维难度也很高，需要对多个数据库或数据表进行管理和维护，增加了系统的故障排查和维护的难度。且在分库分表的场景下，历史问题数据追溯问题是一个普遍存在的问题，由于数据被分散存储在多个数据库或数据表中，导致历史数据的追溯变得困难。

现在我们依然有很多上层业务都依赖在线库MySQL，这些上层业务很多都是根据MySQL分库分表进行的设计和实现，所以在线库从MySQL替换成OceanBase还需要花一些时间。但引入OceanBase数据库后，完善了DB侧对原生分布式库表的支持能力，对于大存储量、改造分库分表逻辑难度比较大的业务提供了更便捷的可行方案。

另外，由于在线业务的逐步接入，下游数据仓库等业务也提出了基于Binlog订阅等需求，OceanBase4.2.1版本提供了Binlog服务，对于分库分表类业务的下游接入可以直接通过该服务来提供，降低了下游需要逐个MySQL集群订阅Binlog的复杂度。

第二，在技术演进方面，我们首要的任务是架构优化。目前，我们正深入调研AP特性，旨在探索用OceanBase替代内部纯AP数据库产品的可行性。在备份方面，我们已顺利完成OceanBase与内部S3存储的备份验证工作。下一步，我们将把OceanBase的备份功能具体对接到公司的备份平台，以进一步完善和优化备份体系。

第三，在业务支撑方面，我们计划进一步扩大OceanBase在内部业务的应用范围，并编制相关文档，详细介绍OceanBase的特性，以便业务团队在选型时能够迅速做出决策。同时，我们还将不断努力，提升OceanBase在业务中的使用体验。

第四，在团队建设方面，我们将使用两个方式开展：一是定期组织内部团队分模块研究OceanBase的机制，并开展分享活动，以提升团队对OceanBase技术的整体掌握水平；二是构建知识体系，针对使用OceanBase过程中遇到的问题，进行总结和沉淀，形成宝贵的知识资源。

第五，在完善工具平台方面，我们将继续研究ODC与Binlog服务等工具的更多能力，并持续优化OceanBase与内部管控平台的连接，优化OceanBase生命周期的管理和自动化流程，提高其精细化管理程度。同时，我们还将接入内部告警平台，完善相关流程，实现更高效的协同工作。，

第六，在最佳实践探索方面，新数据库的引入对于DBA的考验也有所增加。在保证数据库稳定的前提下，也要充分对硬件、服务配置等维度进行合理的选型和持续优化，以便更好地挖掘OceanBase潜力。我们将持续与OceanBase团队一起实践和探讨，找到OceanBase最有效率和最具成本效益的使用方式，为业务的快速和稳定发展提供强有力的支撑。

老纪的技术唠嗑局 不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星 吧！你的每一个Star，都是我们努力的动力～
https://github.com/oceanbase/oceanbase