当前位置：首页 > article >正文

关于OceanBase 多模一体化的浅析

article 2024/9/20 2:15:56

在当今多元化的业务生态中，各行各业对数据库系统的需求各有侧重。举例来说，金融风控领域对数据库的高效事务处理（TP）和分析处理（AP）能力有着严格要求；游戏行业则更加注重文档数据库的灵活性和性能；基于位置服务的业务则对GIS空间数据库严重依赖。这种业务场景的多样性使得数据库运维过程中面临着多重挑战，包括备份与恢复、在线巡检、安全保障与法规合规、故障定位与排查、系统维护与升级以及性能优化等。

传统的单一数据库系统难以全面满足多样化的业务需求。运维过程中，多数据库系统的多样化诉求不仅增加了数据库管理员（DBA）的工作量，还对其技能提出了更高的要求。随着引入数据库系统的增多，运维的复杂程度成倍增加。

这种情况下，数据库的多模能力显得尤为重要，它能够统一管理和处理不同类型的数据，在提高效率的同时简化技术栈，从而满足复杂多变的业务需求。本文将介绍 OceanBase 带来的多模一体化功能特性及其应用场景。

一、OceanBase 多模融合一体化引擎

OBKV 是 OceanBase 承载多模 KV 能力的核心组件，旨在提供低成本的大规模结构化和半结构化数据存储，确保在简单操作接口下实现卓越的访问性能。在技术实现上，OBKV 无需 SQL 层交互，可直接基于 OceanBase 的分布式存储构建多种多模 KV 形态。例如，OBKV 目前支持兼容 HBase 接口的 OBKV-HBase、兼容 Redis 协议的 OBKV-Redis，以及基于表格接口的 OBKV-Table 等多种形态。在分布式存储和多模形态之间，OBKV 引入了一个名为 TableAPI 的框架层，为模型层提供封装的存储和事务调用能力。

在 OceanBase 的架构体系中，SQL 引擎和多模 KV 都建立在分布式存储引擎之上。许多用户可能会好奇，为什么 GIS、JSON、XML 等数据类型会被放在 SQL 引擎中，而不是多模 KV 中？这一决定主要基于业务的考虑。众所周知，GIS 领域的业务大多使用 PostGIS 数据库，Oracle 的 XML 数据库非常强大，被广泛使用，JSON 作为文档类型的标准格式，各个主流关系数据库都有比较完备的支持。从业务角度来看，这些用户已经习惯于使用 SQL 进行访问。因此，OceanBase 将这些多模数据类型融入 SQL 引擎中，以便更好地满足用户的使用习惯和业务需求。

1719310460

图 1：OceanBase 多模融合一体化引擎

另外，用户在大数据分析场景里使用 HBase，在缓存或数据结构丰富的场景下使用 Redis。而 HBase 和 Redis 的开源生态非常活跃，从业务角度来看，用户更希望使用原生的 API 访问这些数据引擎。因此，OceanBase 的多模数据库按照用户的接口使用习惯分为两部分：一部分是 SQL 引擎里的 JSON、GIS、XML，未来也会增加向量数据类型；另一部分则与当前主流的 NoSQL 数据库使用习惯一致，存在于多模 KV 里。

多模 KV 和 SQL 引擎处于平行状态，多模 KV 通过直接连接存储引擎，无需经过 SQL 层，因此在简单的 KV 场景下，使用多模 KV 接口比使用 SQL 接口性能高 30% 左右，且多模 KV 和 SQL 引擎互不影响。在正常业务场景中，如使用 HBase 的场景，我们建议用户在一个 OceanBase 集群里使用专门的 HBase 服务。

除了数据引擎本身，数据库的周边生态工具也非常重要。OceanBase 在引入数据引擎的同时，还引入了一系列周边监控和运维工具。通过一体化运维和共享工具体系，OceanBase 实现了使用一套工具即可完成 SQL 和 KV 的运维。在这种场景下，DBA 只需掌握一套引擎，而业务部门则可以根据需求选择相应的模型，从而实现更高的效率和灵活性。

二、浅谈多模融合一体化的价值

业内许多数据库的多模功能通常以解决方案的形式呈现，其中每个引擎都是垂直的，即每一种模型都是一个数据库，它们之间相互独立。OceanBase 采用了一种不同的方法，在 OceanBase 中无论是 KV 多模还是 SQL 多模，它们都共享同一个分布式存储引擎。例如，SQL 多模会共享 OceanBase 的 SQL 引擎，包括其中的执行及优化能力。由于这种共享，OceanBase 底层的分布式存储引擎的演进也会统一影响到多个模型。这样的设计带来的好处在于，用户不再需要担心单一模型的生态和演进问题。不但可以实现多模融合计算、多模融合存储、多模一体化运维，基础引擎的优势将会乘以 N。

（一）融合计算的价值

○ 选择最优的执行代价

以基于位置的服务为例，假设需要查询距离最近且评分超过 4 分的奶茶店中的前 10 条好评。这个需求涉及多个方面：

首先，需要筛选评分超过 4 分的奶茶店，这是普通的结构化关系型数据库擅长的处理，即以“评分 4 分以上”作为过滤条件即可。

其次，需要找到距离最近的奶茶店，这是典型的基于位置的查询服务，是空间数据库擅长的处理。

另外，需要考虑 10 条好评，这里的评价一般都是文本，文本内容是否属于好评很难判断，可以基于文本内容提取文本语义做向量检索，从而得出判断。

如何结合这些查询条件，最终选择何种执行路径呢？是使用向量索引还是使用空间索引，还是使用普通 TP 索引？OceanBase 通过多模引擎和优化器的融合，能够选出最优的执行路径，从而为客户带来更佳的查询结果、查询响应时间和资源消耗。

○ 异构数据无缝转换 & 计算

多模融合计算还能够服务于异构数据的无缝转换和计算。随着半结构化数据和结构化数据的增多，当普通的关系型数据需要与 JSON、GIS 统一进行查询时，常规的关系引擎是针对关系模型进行 SQL 查询和优化的。然而，当引入半结构化数据和非结构化数据后，在实际的计算场景中，如何让半结构化数据更有效地利用已有资产，以达到最优效果呢？以下是两个例子：

第一个例子：底层存在结构化表和半结构化表。以 JSON 为例，文档数据库是带有嵌套结构的模型，与普通的关系型数据库相比，JSON 的计算处于劣势。因为关系型数据库是二维表，而 JSON 则具有层次结构。在多模方面，关系型数据库提供了诸如 JSON Table、XML Table 等模型转换的能力。通过用户定义的模型，将 JSON 转化为关系二维表，然后通过执行引擎和现有的关系数据进行 Join 等计算。

第二个例子：底层都是结构化表，但业务希望使用半结构化的数据。典型的例子是游戏场景。游戏场景下的用户数据通常是带有层次结构的 JSON 数据，例如用户可能具有装备属性、个人信息属性，而装备又可以细分为不同的分类，数据通过层次不断嵌套。在业务层面，如何处理用户的所有数据呢？虽然关系型数据库直接存储 JSON 是一种较好的方式，但 JSON 也存在一个问题：JSON 数据是自解释的，JSON 对象引用的所有内容都需要完整的存储在 JSON 对象中，从而会导致数据冗余存储。因此，在设计表结构时，通常会提取公共部分，以尽量降低各个数据表之间的冗余度。在这种情况下，OceanBase 提供了通过关系表向半结构化数据转换的逻辑。例如，通过一体化的执行引擎做通用的关系计算，计算完成后再通过相应模型的聚合能力(比如 XML 或 JSON AGG 函数等能力)，将结果聚合成相应的数据返回给业务。

1719310754

图 2：异构数据无缝转换&计算

（二）融合存储的价值

在半结构化数据中，实现编码的工程难度非常大，因为数据本身的结构化程度不高，市面上大多数数据库产品也没有对 JSON 数据做压缩编码，只是按照文本或者二进制的方式简单存储。OceanBase 可以更好地解决这一问题，而且，OceanBase 的编码能力与 MySQL 等数据库相比，有着数量级的降本优势。

1719310842

图 3：结构化&半结构化数据存储降本

举个例子，考虑用户在高德地图上显示的轨迹，每个时间段内都会采集一个点，这些点组成了轨迹，而这些轨迹就相当于一个 double 对(分别表示经纬度)的数组。数据库可以很容易地压缩单一 double 类型的数据，但是轨迹这种基于 double 对和变长数组嵌套组成的半结构化数据的压缩就相对困难许多。但是如果把轨迹数组拆解成两个普通 double 数组，就可以复用 OceanBase 已有的 double 编码技术，极大提升轨迹数据的压缩比。在 OceanBase 中，我们正是通过提取半结构化数据的结构特征的方式，再复用 OceanBase 已有的数据编码技术，解决半结构化数据编码压缩的问题。

同样的，我们知道，JSON 在使用上不需要预定义 schema，在数据库中一般是按照文本或者二进制存储，压缩率一般不及普通数据类型。但是在大多数情况下，数据表中同一列的 Json 数据的结构是比较类似的。基于这一特征，数据库可以提取公共部分，即一个结构化部分和一个半结构化部分，最大限度利用存储引擎的 encoding 能力。这样，即使存在半结构化数据，也能够达到和关系型数据库相似的存储成本。

三、聊聊 OBKV 的两款 NoSQL 模型

目前 OBKV 已经支持两款 NoSQL 相关的模型，即 OBKV-HBase 和 OBKV-Redis。

（一）OBKV-HBase

○ HBase 在大数据处理中的优缺点

HBase 是业内非常流行的分布式 KV 数据库，有着优秀的横向扩展性以及高性能的简单读写能力，能够支持大规模数据的分布式存储和处理。

在大数据处理场景，HBase 被广泛使用，比如用于存储业务原始的海量日志/消息/数据，离线数仓计算后的结果集批量导入到 HBase 中供业务做快速查询，在实时数仓中作为维表的存储，提供极致的点查和范围查询能力。这种场景下，业务一般将 HBase 作为 KV 数据库来用，主要关注 KV 的写入/查询/存储等基础能力。

HBase 定位是一个 KV 数据库，主要提供简单的数据访问能力，不支持二级索引和数据计算。为了解决这些限制，开源社区提出了 Phoenix，它在 HBase 之上构建了常用 SQL 以及二级索引能力，增强了 HBase 对结构化数据的处理能力。

○ 适用场景对比

对于普通的 HBase 场景，OceanBase 的 OBKV-HBase 可以轻松胜任，并且提供相比 HBase 更高的性能。对于结构化场景，也可以使用 OBSQL，通过索引和灵活的算子，不仅带来数倍的压缩率，还能够为用户提供更大的灵活性。

1719310976

图 4：OBSQL & OBKV-HBase 覆盖 HBase 生态场景

○ HBase 替换场景

在 OceanBase 替换 HBase 的实际场景中，下面左图展示了贝壳的情况。贝壳案例主要在 Flink 中进行 ETL，将复杂的字符串转换为 ID，在下游基于 ID 进行分析，返回数据时，替换 ID 和字符串。挑战在于，Flink 中的流式计算需要频繁访问字典服务，因此字典服务需要具有非常低的时延和非常高的吞吐量。使用 OceanBase 的 SQL，数据处理将会变得非常简单。

右图仟传的场景稍微复杂一些。原始数据经过 Kafka 流到 Flink，Flink 会对用户数据和事件数据进行分析，如果用户数据不完整，Flink 会补全并插入数据库。由于事件数据本身是一个嵌套结构，有可能在一个事件数据中引用另一个事件，Flink 在获取事件后，会重新关联事件并补全，然后传递给下游。在这种情况下，OceanBase 具备处理海量数据存储和极致读写能力的优势。

1719311020

图 5：OceanBase HBase 替换场景

（二）OBKV-Redis

○ 兼容 Redis 接口的持久化数据库

Redis 在极致 RT 和高吞吐率的场景下表现出色，比如在广告、游戏等现金流业务中，需要与 Redis 进行多次交互的情况下，业务的访问延迟直接影响到收入。然而，在我们和用户的交流中收到很多类似的反馈，在传统的 RDS 和 Redis 组合场景中，成本较高，业务架构复杂，因为业务不仅需要感知 Redis，还需要感知 RDS，并且需要关注它们之间的一致性。同时，通用的解决方案放在业务层并不合适，大多数场景并不需要 200-500 微秒的实时延迟。我们进行了一组数据测试，如下图所示。将 OceanBase 的延迟控制在 1 毫秒内，在不同数据量的情况下观察整个数据库的吞吐情况，最终结果仍然是令人满意的。

1719311096

图 6：OBKV-Redis，兼容 Redis 接口的持久化能力

此外，在冷热数据场景中，Redis 存在一定的难解的问题。例如，在游戏场景中，系统中有很多玩家，但只有少数玩家的游戏频率较高，其他玩家由于工作等各种原因每周只登录一次，因此数据存在明显的冷热分离。如果将所有数据都存储在内存中，那么基础设施成本将会很高。因此，OceanBase 一方面致力于解决数据库和缓存一致性的问题，让用户可以将 Redis 用作数据库；另一方面希望通过区分冷热数据，将热数据存储在数据库的缓存中，将冷数据存储在数据库的磁盘中，从而降低业务成本。通过缓存数据库一体化，为 80%的“RDS + Redis”架构场景降低成本。

○ Redis 替换场景

以陌陌为例，过去在业内某知名数据库的场景中有 158G，迁移到 12C40G 的 OceanBase OBKV-Redis 租户后，OBKV-Redis 的存储量仅为 95G。对业务来说，收益主要有三点：

首先，不但性能得到了提升，而且存储空间从 158G 减少到 95G，成本降低明显。

其次，在 P90、P99 和 P95 的实时性场景下，性能也能够满足业务需求。

最后，通过在一个 OceanBase 集群中将原 RDS 和原 Redis 业务分成不同的租户，对原 RDS 业务进行压力测试，使其达到极限，然后发现对原 Redis 业务集群基本没有影响。

对于业务而言，这意味着降低了存储成本，复用了 OceanBase 技术组件的能力，并通过 OceanBase 的多租户功能将不同业务的 Redis 集群和 RDS 集群融合到一个 OceanBase 集群中，实现了成本降低。过去，一套 Redis 需要进行复杂的部署，有时甚至需要进行物理隔离，而现在只需要进行 OceanBase 的租户隔离就可以达成期待的业务效果。此外，还有一体化运维。对于业务来说，普通的 Redis 将逐渐停止运维，并全部迁移到 OceanBase，实现了 Redis 和 RDS 在 OceanBase 上的一体化运维，节省了 Redis 运维工作所需的人力成本，以及对技术体系的要求。