本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接即可获取完整版内容。
作者：王新然，好未来数据库专家
好未来集团围绕教育开展传统素质教育和数字教育，知名品牌包括学而思素养、学而思网校、彼芯等。公司业务覆盖线下面授课程、线上网络课程以及课后托管服务。我们提供一系列人文美育和科学制造课程，旨在促进孩子的全面发展。公司目前正积极推动智能硬件业务，在市场上均获得了良好反响。
同时，公司在大型模型领域也进行了深度投入。2023年，我们发布了国内首款数学领域的大模型——MaathGPT；2024年又推出了基于该大模型的App“随时问”，不仅能直接给出答案，更能对用户提出的问题进行知识点梳理，通过逐步引导帮助用户解决问题，重点在于培养用户的解题思路。
作为国内领先的教育科技企业，旗下业务众多、数据海量，底层数据系统涉猎MySQL、Redis、MongoDB、Pika、RDS、PolarDB、CDB、TDSQL-C等，以及采用阿里云、腾讯云、百度云等多云架构。迫于分库分表的困境，以及受资源隔离与资源碎片等问题困扰，新增OceanBase技术栈以解决问题。试点后不仅提升了可用性与资源利用率，还降低了运维复杂度并带来额外的成本效益。
一、选型前的三个困境与四项选型因素
作为一家业务多元化的企业，选择一款适合的数据库对于公司业务发展至关重要。由于集团业务线丰富，每个业务线会根据自己的实际业务场景做数据库选型，集团的数据库服务是以混合云的模式对内部业务提供的。我们既在IDC内自建了大量的数据库服务，也使用了多家云厂商提供的各类数据库产品，涉猎的数据库种类比较广泛。在使用了如此多的数据库产品之后，我们为什么还会继续考虑选型OceanBase？ 有以下三个方面的原因。
第一，自建服务中有大量MySQL服务，作为传统的单机数据库，MySQL性能和容量很容易达到瓶颈。同时，传统基于中间件的分库分表解决方案对分布式事务的支持不友好，还会增加运维侧的复杂度。
第二，传统数据库主要通过单机多实例方式部署，缺少资源隔离能力，会为线上业务的稳定运行埋下隐患。同时，由于管控面对的是非常零散的物理机资源，且对资源的申请和回收只是在元信息层面修改，势必会产生大量的资源碎片。
第三，目前资源部署模式不具备可弹扩能力，资源在分配时都会留有较大冗余，导致整体数据库服务资源利用率较低，资源浪费严重。
基于以上困境，我们在选型一个新的数据库时，主要关注四个方面的能力。
（一）架构设计，决定数据库的性能和容灾能力
图1是OceanBase4.x版本的架构图，具备以下特点。
图1 OceanBase4.x版本架构
（1）多副本：一般部署为3 Zone或5Zone，每个Zone由多个服务器节点（OBServer）组成；
（2）对等节点：每个节点均有自己的SQL引擎和存储引擎，自主管理各自承载的数据分区，TCP/IP互通，协同服务；
（3）无需存储设备共享：数据分布在各个节点上，不基于任何设备级共享存储技术，不需要SAN网络；
（4）分区级可用性：分区是可靠性与扩展性的基本单元，自动实现访问路由、策略驱动负载均衡和自主故障恢复。
（5）高可用+强一致：多副本+Paxos分布式协议的高效、高可靠工程实现，确保数据（日志）持久化在多数派节点成功。
OceanBase v4.x的单机分布式一体化架构能够让业务的大部分请求在本地作为单机事务来执行，避免分布式事务带来的消耗。同时，如果对可用区或Zone设置优先级，甚至能让一个租户所有的请求都转变为单机事务在本地执行。这种性能上的优势对于业务来说非常有吸引力。
（二）多租户能力，实现资源隔离及灵活配置
如图2所示，OceanBase提供了原生多租户能力，支持租户单独配置数据副本数量、副本类型、存储位置及计算资源等。同时，OceanBase支持单个租户的动态扩缩容，可在线扩展和调整配置。在集群内部提供自动化的运维手段，保证了租户之间的资源完全隔离，租户之间数据也相对安全，能够帮助我们解决线上资源混合的风险。
图2 OceanBase提供原生多租户能力
（三）存储压缩技术，获得额外的成本收益
OceanBase提供了非常高级的数据压缩技术，除了能够解决性能和可用性的相关问题，还能获得不错的成本效益，这主要得益于以下三个关键技术。
（1）基于数据变长-定长的存储压缩技术： 通过使用压缩率较高且解压缩较快的压缩算法对数据进行压缩，提高数据压缩倍率，减少数据的存储成本。同时由于LSM-Tree的结构特性，采用读写分离设计和行级细粒度记录更新，变更数据保存在内存中，并批量写入磁盘。因此能达到内存数据库级写入性能和磁盘数据库的存储成本，并消除了传统B+Tree的磁盘随机写瓶颈和存储空间碎片化问题，使得数据写入性能比传统的实时更新数据块的方式更高。
（2）基于数据编码的存储压缩技术： 采用行列混合存储格式，磁盘数据块按列组织，自研一套对数据进行行列混存编码的压缩方法（encoding），使用行列的字典、差值、前缀等编码算法，在通用压缩算法之前对数据做了编码压缩，从而带来更大的压缩率。
（3）基于数据日志分离的低成本存储技术： 传统的Paxos协议中，系统需要三个副本（或五副本），OceanBase数据库将用户数据和日志数据分离，比如日志数据基于Paxos协议使用三副本（或五副本）存储， 而用户数据本身可以使用两副本（或三副本、四副本）进行存储。在保障相同可用性前提下，数据日志分离可节省20%-40%的用户数据存储成本。
此外，OceanBase还具备以下优秀特性：动态修改写内存、静态数据无修改、支持高压缩数据的批量写、数据强一致性校验、对SSD十分友好的无随机写等。
（四）生态工具，以最小的成本构建新的数据库运维体系
除了内核能力十分强悍外，OceanBase还提供了非常丰富的生态工具（见图3），涵盖了服务运维的全生命周期，比如评估改造、实时迁移、开发管理、生产运维、复制订阅、安全管控、诊断自治。借助这些强大的工具，可以让我们以非常低的成本完成OceanBase运维体系的搭建。
图3 OceanBase运维体系
其中，我们使用最多的工具是OCP（OceanBase Cloud Platform）。通过OCP，我们日常运维的大部分操作能够实现白屏化，比如创建集群、新增可用区、新增租户等操作，只需在OCP的页面上通过点击按钮即可完成，整个过程十分简便且可靠。同时，OCP还提供了监控报警、性能分析以及数据备份等功能，使得OceanBase的运维可以变成一件简单而愉快的事情。
此外，我们也关注到OceanBase对MySQL生态也提供了良好的支持，在MySQL 兼容模式下，通过Binlog Service可以将OceanBase的日志转换成 MySQL Binlog的格式，实现对MySQL Binlog协议的全面兼容。业务可以继续使用MySQL生态下的数据同步工具完成相关数据的订阅任务，极大降低了业务的改造成本。
二、解决五大业务场景中的数据库痛点问题
自2022年底至2023年初，好未来集团开始搭建OceanBase基础架构，随后首个业务便开始在OceanBase上试点运行，落地情况如图4所示。至今OceanBase已经稳定运行了两年多，期间展现出了极高的稳定性，线上未发生任何故障或问题。
图4 OceanBase在好未来集团的应用
基于OceanBase的稳定表现，我们计划深入探讨其独特且优秀的特性，将更多业务从其他数据库迁移至OceanBase。接下来，将通过列举OceanBase在好未来五大业务场景中的使用情况，阐述好未来的数据库升级方案。
（一）学习机业务场景：研发成本降低，稳定性提升
“学习机业务”是好未来集团目前较为重要的数据库应用场景。在推出仅两年的时间里，学习机业务经历了用户量的迅猛增长。然而，与一般的互联网业务不同，学习机的用户几乎都是付费用户，且客单价相对较高。因此，该业务目前面临两大挑战：一是数据增长量迅速；二是对数据可靠性要求极高。
针对学习机这一重要场景，我们在进行新的数据库选型时，主要考虑了三个选型要点：
- 一是鉴于业务正处于快速发展阶段，要求数据库容量能够进行水平扩展，包括集群的吞吐量和数据量，同时我们也希望性能不会因为数据量的增加而显著下降；
- 二是新的数据库必须具备良好的容灾能力，以确保在机房故障等极端场景下不会发生数据丢失；
- 三是由于学习机业务除了销售硬件和课程外，还涉及大量的产品运营，因此我们有众多大数据分析的需求，这就要求数据库能够兼容MySQL binlog生态。
基于这三点要求，我们经过调研发现，阿里云提供的PolarDB-X（见图5，下文简称“PolarDB”）和蚂蚁集团自研的OceanBase均符合我们的需求，且都是开源产品，均支持分布式存储，均有较高的数据可用性和可靠性。为了做出更明智的选择，我们内部对这两个产品进行了功能比较。
图5 PolarDB-X架构
两款数据库的功能表现如图6所示。具体而言：
- 二者的RTO（故障恢复时间）都小于8秒，且能够做到数据零丢失；
- 二者都采用了多副本底层架构，并通过Paxos协议确保了数据的一致性，从而避免了脑裂问题的发生；
- 由于目前二者都尚未具备Serverless技术，因此自动弹性扩展能力均有所欠缺；而二者的横向弹性扩展都能够通过增加节点来实现；
- 二者都支持渗流控制和Kubernetes容器编排技术；
- OceanBase的原生分布式架构得益于其租户特性，资源隔离优势凸出；
- 成本也是我们关注的一方面，OceanBase的研发、运维成本都相对更低。
图6 PolharDB-X和OceanBase的功能对比
在性能方面，我们采用8核64G/64 threads，且三机房部署的压测环境对MySQL、PolarDB和OceanBase进行了对比，结果如图7所示。
图7 MySQL、PolarDB和OceanBasex性能对比
最终，我们选择OceanBase作为数据库的主要原因在于其生态系统。尽管PolarDB的数据库内核非常强大，但其周边平台却相对匮乏。目前，PolarDB主要提供黑屏命令行和Kubernetes Operate等部署方式，这可能对我们的研发投入成本构成较大压力。因此，在可用性和内核能力相当，且性能相近的情况下，我们更倾向于选择一个投入产出比更高的方案。
选择OceanBase后，我们的下一步计划是针对学习机业务制定一个高可用方案，该方案将充分利用OceanBase 4.2.5版本提供的主力租户功能。值得注意的是，虽然主力租户功能在之前的版本中可能已经存在，但4.2.5版本可能提供了针对业务一致性的访问方式。这意味着在主备切换后，业务侧无需感知到任何变化，从而确保了业务的高可用性。
为了确保在极端情况下业务仍能持续运行，我们保留了原有的MySQL集群，并通过OMS的反向同步机制，将实时数据回流到OceanBase集群，以防出现故障时主备集群都无法使用的情况。一旦出现故障，即可切回MySQL继续为业务提供服务。虽然这一架构从成本角度来看可能不是最优的，甚至相比原方案成本有所增加，但考虑到业务对高可用性的严格要求，这些投入是值得的，架构如图8所示。
图8 主、备集群和回滚集群架构
此外，我们的学习机业务对MySQL的binlog有强依赖。一方面，业务依赖于binlog数据的实时生成来进行实时报表的计算，帮助用户查看学习报告等场景；另一方面，我们也通过这些数据来进行运营层面的决策，如为学生推荐合适的课程或调整运营方向。因此，我们需要数仓类的解决方案来满足这些需求。
为此，我们采用了OceanBase提供的binlog service方案。如图9所示，该方案完全兼容MySQL 5.7的binlog格式，并且天然支持像Canal、Flink等成熟的MSL生态工具。这样，我们就能够利用这些工具来处理和分析binlog数据，满足学习机业务在实时报表计算和运营决策方面的需求。
图9 binlog service方案
在这套方案中，我们的业务几乎无感地从MySQL切换到了OceanBase，满足我们对数据订阅的需求。
在这项业务上，OceanBase给我们带来的收益有哪些？
借助OceanBase的分区表能力，业务团队无需再关注分库分表的逻辑，很大程度上节省了研发成本。过去每当遇到容量问题，都需要进行拆库操作，但现在只需不断增加OBServer就能满足数据存储需求，节省大约10个人力/天/次。另外，OceanBase的跨计算能力使得RTO小于8秒，RPO等于零，这极大地提高了系统稳定性。
此外，OceanBase在大数据订阅binlog方面也做得很好。它统一收敛了binlog的订阅入口，使得大数据和数据库之间可以实现高可用能力。
然而，在使用过程中，我们也发现了一些注意事项。
（1）在创建分区表时，不建议一次性把未来的表都建出来，因为数据存在热点问题，可能会导致某些OceanBase server的存储过高（最新版本针对数据均衡有所改进，暂未体验），而其他server的存储则很低。为了解决这个问题，我们可以利用OceanBase提供的分区管理能力，每次只多建一个或两个表。
（2）在部署OceanBase log process时，最好指定binlog的存放目录，否则默认会放在根目录下，这可能会导致根目录空间不足。如果之后再更换目录，过程会比较麻烦，而且需要重启OceanBase log process，可能会对业务造成损失。另外，OceanBase当前不支持flash log with vlog命令，这使得我们不能直接使用MySQL dump工具进行全量数据拉取，需要业务端进行一些改造。
（3）当使用OMS进行分区表和增量同步时，需要注意设置相应的参数和调整GVM的内存大小，否则可能会导致全量校验不通过或增量同步失败。截至2025年2月，我们已经部署了五个OceanBase集群，并有31个租户正在运行。
（二）多机房容灾场景：解决数据脑裂问题，数据零丢失
在使用MySQL数据库时，我们面临重大的容灾限制。例如主机房故障时，导致数据脑裂。过程如图10所示，在T1时刻，若A机房出现网络隔离，高可用组件检测到后会主动将主库切换到B机房。然而，若此后A机房网络恢复，就会出现双写问题，从系统整体来看，这将导致数据脑裂。对于我们的业务而言，数据不可用或丢失或许还能勉强接受，但数据脑裂的问题却是最棘手的。
图10 MySQL主机房故障过程
因此，容灾问题是我们迫切需要解决的难题。
在引入OceanBase之前，我们的应对方案是：在机房发生故障时，不采取自动化的止损措施。而是先等待业务将流量切换到B机房后，再手动将数据库迁移至B机房。然而，这种方案的问题在于：整个集群的故障止损时间大幅延长，因为这是一个非全自动化的流程，又因为数据同步采用的是主从同步方式，并且存在跨机房的网络延迟，所以无法保证数据不丢失。尽管该方案能够从机房外部调度业务流量，但机房内部的定时任务等流量却无法被有效调度，这仍然可能导致数据脑裂的问题。
针对这些待解痛点，OceanBase提供了两种容灾方案。
第一种方案是“同城三中心”（见图11），OceanBase的数据以多副本形式存在，且副本间通过Paxos协议确保数据一致性，只需将集群部署在三个机房中，即可解决机房级别的故障问题。
图11 同城三中心
其中任意一个机房发生故障后，其余机房中的多数派副本仍能继续提供服务。这样一来，整个集群依然能够对外提供服务，业务只需将流量从故障机房切换走，即可完成止损动作。通过OceanBase提供的同城三中心能力，我们能够确保集群的故障恢复时间小于8秒，且数据零丢失。
然而，此方案有一个局限，即对三个机房间的网络质量要求极高。由于业务请求可能涉及跨机房调用，若机房间网络不稳定或业务对网络延迟极为敏感时，可能不宜采用。
第二种容灾方案名为主备租户，见图12。简而言之，就是在机房一和机房二分别部署两套独立的OceanBase集群。在机房一创建租户的主副本，在机房二创建该租户的副本。OceanBase内部配备了一个名为日志传输服务的组件，能够实时将主副本的变更操作同步到副本上。
图12 主备租户
在这一容灾方案下，主备租户的数据一致性得到了保障。从容灾范围来看，此方案相较于第一个方案更为优越，因为它能够应对集群级别的故障。例如，若集群A发生故障，我们可以将业务无缝切换至集群B继续服务。然而，该方案也存在一些不足。
- 止损过程需要人工干预。当机房A出现问题时，我们需要手动将备租户升级为主租户，这一过程非自动化。
- 无法完全解决之前提到的数据脑裂问题，但相较于MySQL的同步性能和同步延迟，问题已大幅减少。
因此，经过综合考虑机房间的网络质量和延迟后，我们最终决定采用方案一。
确定容量方案后，下一步就是制定从MySQL迁移到OceanBase集群的方案，整体架构图如图13所示。得益于OceanBase丰富的配套工具，其中OMS具备双向同步能力，极大地简化了迁移过程，只需在三个机房中搭建一套新的OceanBase集群，然后利用OMS进行双向数据同步，即可完成整个集群的迁移和搭建工作。迁移过程非常顺利，且对业务影响较小。
图13 业务迁移架构图
（三）AI业务场景：存储成本每月节省86%
随着AI浪潮的到来，我们面临着海量多模态数据存储的挑战。好未来自身在AI领域的投入显著增加。为了支持各业务线快速接入AI的能力，我们部门推出了一项AI基础服务，旨在加速业务与AI技术的融合，提升整体业务效能。
然而，随着接入服务的增多和业务的发展，我们遇到了一个显著问题：需要留存的数据量急剧增加，且数据增量异常庞大（见图14）。具体而言，我们服务的数据每月增长量接近10TB。如果使用传统MySQL服务器来承载这些增量数据，一套标准的服务器甚至难以存储一周的数据量。这不仅限制了数据的存储能力，也对业务的持续发展和数据利用构成了障碍。
图14 数据量增长趋势
此外，传统的数据库方案还要求业务进行复杂的分库分表操作，这不仅增加了技术实现的难度，也显著提升了整体的成本。面对这一痛点，我们结合OceanBase的海量数据存储能力加上云的极致弹性，探索出一条新的解决方案。
我们利用OceanBase的分区表功能（见图15），使每个OBServer能够承载单个表的部分容量，从而分散数据存储压力。同时，通过OceanBase的高级压缩技术有效控制数据的增长速度，确保数据存储处于可控范围。此外，添加云上ECS购买与节点，在OceanBase分析表能够存储增量数据的基础上，我们每季度购买云上的ECS（弹性计算服务），并手动将新分区的日志流量切换到新的ECS上，以满足数据增长的需求。
图15 OceanBase分区表功能
但这种解决方案面临两个问题：一是成本不可控，随着数据量的快速增长，我们发现需要购买的ECS数量越来越多，甚至可能每月都需要购买三台，导致成本难以控制；二是数据迁移挑战，虽然我们将ECS添加到节点中，但数据迁移不能由OceanBase自动触发，需要在业务低峰期进行，这对运维工作带来了挑战。
为了解决上述问题，我们制定了以下改进方案。
首先，购买小规格ECS并挂接云盘：我们购买了三台小规格ECS，并在其下挂接了云盘。阿里云单个云盘最高可支持60TB的存储空间，因此我们每次先购买一个4TB的云盘。
其次，云盘升配与OceanBase自动识别：当4TB云盘空间不足时，我们直接在ECS上对云盘进行升配，且此操作无需重启ECS，对OceanBase服务无影响。OceanBase在一段时间后会自动识别新增的硬盘空间，无需我们进行额外操作。
然后，简化运维流程：现在的运维工作大大简化，只需在磁盘报警时对相应的ECS进行云盘扩容即可。这一改进方案为我们带来了极大便利。
当前实施的方案带来了多方面的显著收益。一方面，该方案无需业务方进行任何改造，这使得业务团队能够完全专注于业务的整体发展，而无需分心于数据处理或存储方案的细节。这不仅提高了业务发展的效率，还确保了业务团队能够充分利用其资源和精力；另一方面，该方案成功应对了当前数据量急剧增长的问题。通过高效的存储和处理能力，确保了数据的稳定存储和管理，满足了业务对数据增长的需求。这些优势使我们得以更好地支持业务的发展，并确保数据的可靠性和完整性。
此外，结合OceanBase与云的弹性方案，好未来实现了成本的显著降低。改进后，我们每个月新增的成本仅为原来传统方案的14%，相当于每个月可以节省86%的成本。使我们能够以更低的成本实现更高的数据存储和处理能力，从而提高整体经济效益。
然而，我们同时意识到当前单个实例的最高存储上限为650TB，这一限制早晚会达到瓶颈，因此制定了未来规划以应对这一挑战。我们计划将历史数据迁移到对象存储服务（OSS）上，以突破存储限制。OSS提供几乎无限存储空间，能够满足我们长期的数据存储需求。同时，我们将利用OceanBase提供的外表能力，对存储在OSS上的数据进行查询和处理。这一结合将确保我们能够满足整个业务对存储和数据处理的需求，同时保持成本效益。
（四） 网校报表：性能较MySQL提升60%
当前，我们的网上推广活动正通过短视频等热门方式进行投放。为了有效运营这些活动，业务团队需要将广告投放、营收数据等相关数据存放到数据库中，以便运营、投手等人员能够实时查看，并根据数据及时调整投放策略。因此，这个平台对数据响应速度的要求非常高。
具体来说，这些报表相关的数据表属于OLAP业务范畴，主要是宽表结构，且数据量级都在千万级。业务团队希望这些宽表的千万级查询能够在秒级内返回结果，否则将严重影响用户的使用体验。在接到需求后，我们考虑到OceanBase 4.3版本提供的列存能力，预期可以给OLAP性能带来显著提升。于是，我们将该租户从OceanBase 4.2迁移到OceanBase 4.3，并将业务使用的所有表都转换成了列存格式。
然而，在初步转换完成后，我们发现仅依靠内存的能力在某些场景下仍然不够，因此又进行了一些性能优化，以确保在所有业务场景下性能都不会出现退化。我们选取了一些业务较为复杂的实例进行测试，从效果来看，OceanBase大部分实例都能在一秒左右返回结果。与MySQL相比，整体性能提升了60%，。
在内存使用的过程中，我们也探索出一些有效方案。这些方案不仅提升了性能，还优化了内存使用效率。个人认为这些方案值得与大家分享，或许对团队和个人都有所启发。
在使用列存技术时，我们初期可能会遇到一些不确定性和挑战，尤其是关于何种查询最适合列存。通过实践，我们得出了一些经验。首先，当查询的过滤条件仅涉及少量列（如单列或几个列）时，即使表中没有其他索引，列存也能表现出良好的性能。然而，如果过滤条件涉及的列很多且没有索引，使用列存可能效果不佳，因为每次扫描列的代价较高。
OceanBase官方也给出了一些建议。由于优化原因，当查询中的聚合函数包含多列表达式运算时，列存可能不太适用。这是因为目前列存对于这类聚合计算中的表达式向量优化尚未及时完成，但后续版本将会有所改进。
另一个特别重要的点是列存技术最适合读多写少的场景。在使用过程中，我们发现频繁更新数据会导致内存性能下降，需要及时进行数据合并以恢复性能（见图16）。
图16 数据合并
总结来说，使用列存表需要满足三个要素：表越宽，列存优势越大；“where”条件最好是单列检索，以提高查询效率；以及场景应该“读多写少”。对于频繁更新的场景，使用列存可能效果不佳。
针对上述优化点，我们给出以下建议：
- 对于OLAP场景，业务在建表时应指定列存标志，或设置租户参数为column，以便后续创建的表都是列存表，从而简化表创建过程。
- 如果业务有批量导入数据的场景，每次导入后应及时执行合并操作，以避免性能大幅下降。
- OCP本身具有合并管理的存储策略，我们可以调整相关参数以实现自动存储性能优化。
（五） 内容审核：确保数据的安全与高效管理
我们的内容审核服务也将机器审核的原始数据及审核结果存储在OceanBase中，确保数据的安全与高效管理。
内容审核这项业务主要围绕课程教学展开，在此过程中，老师与学生间存在大量实时互动。同时，用户还可能通过我们的应用与大型模型进行交互，这三者之间互动频繁。根据当前政策要求，所有实时互动均需经过审核。因此，我们的内容审核服务旨在全面覆盖集团各项业务，对所有互动信息进行实时审核，这让传统数据库面临诸多挑战：
- 由于集团所有业务都需要内容审核，且学生上课时间集中，因此对数据库集群的吞吐量要求极高。
- 业务要求保存所有审核的原始内容及结果，既用于监管，也可能用于后续的人工审核，因此所需存储的数据量巨大。
- 机审数据还需与人工审核及运维平台对接，以便进行运营工作，这涉及复杂的业务逻辑处理。
当我们迁移至OceanBase后，上述挑战得以解决，如图17所示。
- OceanBase凭借其卓越的高可扩展性能，实现了吞吐和容量的按需扩容，一举解决了业务在数据库使用中遇到的核心难题。
- OceanBase内置的并行查询与向量化引擎大幅提升了查询性能，为用户带来了更加流畅的体验。
图17 迁移至OceanBase后的情况
三、业务探索，用OceanBase替换更多数据库
随着OceanBase深入到好未来更多的业务场景中，我们发现其可以做的事还有很多，甚至能更好地完成不少传统数据库在做的工作。因此，为了进一步简化技术栈，提高系统稳定性，我们尝试用OceanBase替换更多数据库。
（一）OceanBase列存替换ClickHouse
OceanBase在2024年发布的4.3版本主打列存功能，可替代当前的ClickHouse服务。集团目前仅用ClickHouse存储日志中心清洗后的数据，这些数据经实时聚合后用于监控大盘和业务高峰的盯盘。为节省人力成本，我们选择用OceanBase的列存功能来替换ClickHouse（见图18）。
图18 通过OceanBase的列存功能替换ClickHouse
之所以替换掉ClickHouse，是因为相较而言OceanBase列存具备几大显著优势。
（1）OceanBase4.3版本引入了全新的列式存储及限量化功能，大幅提升了其AP能力，官方数据显示其性能已与ClickHouse相媲美。
（2）OceanBase列存还兼容行式存储。这意味着在同一个集群中，既可以存在列存表以满足AP业务需求，也可以存在行存表以支持TP业务，从而实现了业务场景的灵活覆盖。
（3）OceanBase列存允许对列存表或行存表添加多种索引，如行存索引或列存索引，这使得单张表能够应对多种业务访问场景，提高了数据访问的灵活性和效率。
（4）OceanBase还支持物化视图、旁路导入等高级功能，这些功能为业务开发提供了更多AP使用场景的应用可能性，进一步拓展了其应用范围。
（5）OceanBase对复杂查询的支持能力明显优于ClickHouse,由于后者擅长做单表操作, 对于复杂的查询如join操作, 常常局限于内存大小, 导致其能力捉襟见肘。
（二）OBKV替换Pika
由于业务场景涉及在线教学，老师和学生之间的互动频繁，包括老师的涂鸦信息和学生的提问等，都以消息形式存储。最初我们选择将信息存放在Redis中，架构如图19所示，但由于数据量迅速增长导致了成本过高，难以承受。因此，我们转而选择了Pika作为替代方案。
图19 消息存储架构
然而，在使用Pika的过程中，我们遭遇了几个关键问题：
- Pika偶尔会出现性能抖动，导致服务短暂卡顿；
- 在进行数据库运维操作如主动切换时，会触发全量同步。鉴于Pika的数据量庞大，达到数千GB，一次全量同步对业务构成的风险相当高；
- 当前我们使用的Pika版本较旧，而新版本3.5虽已发布，但缺乏平滑的升级方案，这给我们运维Pika带来了不小的困境。
在调研OBKV时，我们意外发现它是替换Pika的极佳选项。
- OBKV与OceanBase共享相同的底层架构，确保了其存储性能稳定，能够实现RTO小于8秒且RPO为零；
- OBKV推出了Redis模式，该模式完全兼容我们现有的Redis协议，意味着业务迁移到OBKV时，无需对业务层进行任何改造；
- OBKV具备出色的数据压缩比，鉴于我们消息体量大，这一特性将显著降低成本。
性能优势，如图20所示。
图20 OBKV与Pika性能对比
四、未来期望
以上是好未来集团升级数据库方案的一些经验，虽然，OceanBase带来的收益满足我们的预期，但在使用OceanBase过程中，我们也希望它能够更加完美。
首先，是对OMS的需求。正如之前提及，OceanBase不仅数据库内核强大，其周边的生态工具也极为出色，尤其是OMS，集数据传输、数据订阅、数据校验等多功能于一体，功能全面。我们期望未来OceanBase能将OMS作为一个独立且核心的产品来持续发展和完善，以更好地支持我们的业务。例如，在数据同步方面，无论是MySQL到OceanBase，还是与其他数据库之间的数据迁移，OMS都能助力解决我们日常运维中遇到的数据同步难题。
其次，在内核层面，我们期望OceanBase能增添两项关键能力。
一是期待推出存算分离架构。鉴于OceanBase当前采用的是单机分布式一体化架构，即CPU、内存与存储集成于一体，我们希望OceanBase能设计出一种存储与计算分离的架构。从当前线上集群的分布状况来看，OceanBase集群的存储资源已使用了约70%，而CPU资源仅利用了10%。这种不均衡的分配常因磁盘容量限制，导致CPU资源无法有效扩展。若采用存储与计算分离的架构，将极大提升资源调度的灵活性。
二是期待用OceanBase来做数据湖。该需求是由我们的大数据团队提出，希望将OceanBase作为数据湖场景来使用，以支持外表查询和联邦查询的需求。
最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
