面对日增亿级数据，BOSS直聘的高性能与高效存储方案

慷规扣 · 2025-6-30 16:22:46

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，欢迎点击链接获取完整版内容。
作者：张煜杰，Boss直聘数据库工程师；王占全，Boss直聘资深DBA
一、BOSS直聘超大规模数据处理面临的挑战

BOSS直聘是在全球范围内首创互联网“直聘”模式的在线招聘产品，目前已成为中国最大的招聘平台。我们负责的BOSS直聘业务场景主要是通过数据库来存储招聘过程中的聊天记录信息，数据量极大，每天都有亿级的增量数据，存储成本高昂，且对查询、分析等业务带来了巨大压力。
受制于传统集中式数据库特性，在BOSS直聘业务持续扩展和数据量飞速增长的过程中，数据存储、处理分析等方面的挑战逐渐放大。每当新业务需求上线之际，我们常常面临一个挑战：由于难以精确预估未来一段时间内的数据量或业务增长趋势，为了确保业务能够迅速投入运行并规避过度设计的风险，我们往往采取较为灵活的初期方案。然而，随着业务的逐步扩张，当数据量增长到一定规模时，数据拆分的问题便凸显出来。这一过程不仅复杂繁琐，还涉及数据库管理员（DBA）、中间件团队以及业务团队的多方紧密协作。各方需要共同努力，以确保数据拆分的顺利进行，这无疑耗费了大量的精力和时间。
为解决上述挑战，同时全面提升业务的稳定性和性能，在2023年年底，我们开始对包括OceanBase在内的分布式数据库产品进行调研。调研内容不仅涵盖了OceanBase的整体架构设计，还包括其功能特性和相关性能指标，并与MySQL进行了特性对比分析。
在国内，传统数据库市场目前仍以MySQL为主流。而MySQL的数据存储存在单节点存储容量受限的问题。这不仅指单机容量有限，还会影响大数据量时的集群备份、恢复及扩容能力。若对时效性有要求，MySQL数据库单节点容量不能过大。根据我们的经验，多数公司的单节点容量上限基本在3T左右，6T的较少，超过3T可能就需要考虑数据拆分。数据拆分通常包括一拆多和多拆多两种场景。若采用一拆多，业务可能需要进行较大的改造。而OceanBase在这方面具有显著优势。不仅在理论上没有容量限制，扩展性更佳，在集群扩容时，更是对业务几乎无影响。
在性能方面，传统数据库也存在不足。一方面，其复杂查询的效率不高；另一方面，单表读写存在性能瓶颈。如果单表写数据量很大，单机无法支撑；同时，在高并发情况下，会有较严重的主从延迟问题，某些业务场景可能无法接受较高的数据延迟。相比之下，OceanBase在复杂查询方面的效率较高，且单表读写不存在性能瓶颈。
在运维体系方面，以某开源数据库为例，其使用不仅限于数据库本身，还需关注周边工具，这往往涉及大量定制修改工作。而若进行数据拆分，不仅业务投入大，DBA的投入也很大。但OceanBase在扩展性方面表现优秀，节点扩容后可自动进行rebalance，人工介入很少。此外，OceanBase的高可用性做得非常好，能达到金融级标准，保证数据零流失，且切换时间控制在8秒以内。
对OceanBase有了初步了解后，我们决定在公司内寻找合适的非核心业务进行试点，对比OceanBase与MySQL和竞品数据库的综合能力。经过研究，我们选择了聊天记录历史归档库作为试点业务场景。
二、BOSS直聘历史归档库技术选型

和招聘相关的聊天记录往往呈现流水型特征，记录写入一段时间后即不会再次访问或更新，写多读少。面对快速增长的在线数据，尤其是访问频率很低甚至为0的历史聊天记录，其占用的在线业务库的存储空间达到PB级别，造成了大量硬件资源浪费，推高了企业IT成本。同时，随着数据量增加，在线数据库查询效率逐步降低，给后续数据变更、扩展造成阻碍。为了解决这些问题，我们需要对历史聊天记录进行冷热数据分离。热数据所在的在线库是多个MySQL集群，采用分库分表的方式，每月定期清理过期数据，滚动写入历史归档库。
作为试点业务场景，我们决定对超大容量的归档库进行数据库选型，参加选型的数据库产品为：MySQL、ClickHouse、OceanBase、某开源分布式数据库（以下简称为DB-U）。我们主要从存储成本与高可用性这两个方面对评估各个产品。
（一）数据库选型：存储成本对比

我们的归档库需要保留三到五年的历史聊天数据，必须解决大容量存储的成本问题。首先我们对MySQL、ClickHouse、OceanBase、DB-U分别创建一张相同的用于存储用户历史消息的表，表结构如图1所示。

图1 用于测试的历史消息表
然后分别写入1亿行相同的单副本数据，并对比其磁盘使用情况，如图2。

图2 参测数据库的磁盘使用情况对比
可以清楚地看到，基于列存进行存储的ClickHouse和拥有超高压缩率的OceanBase这两款数据库的存储成本明显低于MySQL和DB-U，所以我们分别对ClickHouse和OceanBase的存储引擎进行了调研。
1.ClickHouse存储引擎调研

ClickHouse的存储引擎是基于列存的。相比行存存储引擎，ClickHouse同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。

图3 列存相比行存存储引擎的成本优势
不过历史归档库一般都是写多读少的场景，像ClickHouse这种纯列存的存储引擎在这里并不能发挥出查询性能好的优势，相反列存引擎写入性能差的劣势还被放大了。
2.OceanBase存储引擎调研

（1）OceanBase存储引擎架构
<font >OceanBase的存储引擎基于LSMTree架构（如图4所示），将数据分为基线数据（放在SSTable中）和增量数据（放在MemTable/SSTable中）两部分，其中基线数据是只读的，一旦生成就不再被修改；增量数据支持读写。

图4 OceanBase的LSMTree存储引擎架构
OceanBase数据库DML操作插入、更新、删除等动作时会首先写入内存里的MemTable，所以在写入性能上就相当于内存数据库的写入性能，正好适合我们历史归档库写多读少的场景。MemTable达到一定大小时会转储到磁盘成为增量的SSTable（图4中红色箭头部分），转储到磁盘上的过程是批量的顺序写，相比B+Tree离散的随机写，会大大提高写盘性能。
当增量的SSTable达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据和基线数据做一次整合，基线数据在合并完成之后就不会发生变化，直到下一次合并。同时每天凌晨的业务低峰期，系统也会自动进行每日合并。
但LSMTree的架构也存在一个问题，就是读放大（图4中绿色箭头部分）。查询时需要分别对SSTable和MemTable进行查询，并将查询结果进行一次归并，再将归并后的查询结果返回SQL层。OceanBase为了减小读放大带来的影响，在内存实现了多级缓存，例如BlockCache和Rowcache，来避免对基线数据频繁随机读取。
（2）OceanBase数据压缩技术
<font >在这样的存储架构下，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

账号		自动登录	找回密码
密码			立即注册