在当今多样化的业务环境中，各行业对数据库系统的需求各不相同。例如，金融风控场景需要高效的事务处理（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 引擎中，以便更好地满足用户的使用习惯和业务需求。
图 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 条好评，这里的评价一般都是文本，文本内容是否属于好评很难判断，可以基于文本内容提取文本语义做向量检索，从而得出判断。
异构数据无缝转换 & 计算
多模融合计算还能够服务于异构数据的无缝转换和计算。随着半结构化数据和结构化数据的增多，当普通的关系型数据需要与 JSON、GIS 统一进行查询时，常规的关系引擎是针对关系模型进行 SQL 查询和优化的。然而，当引入半结构化数据和非结构化数据后，在实际的计算场景中，如何让半结构化数据更有效地利用已有资产，以达到最优效果呢？以下是两个例子：
第一个例子：底层存在结构化表和半结构化表。以 JSON 为例，文档数据库是带有嵌套结构的模型，与普通的关系型数据库相比，JSON 的计算处于劣势。因为关系型数据库是二维表，而 JSON 则具有层次结构。在多模方面，关系型数据库提供了诸如 JSON Table、XML Table 等模型转换的能力。通过用户定义的模型，将 JSON 转化为关系二维表，然后通过执行引擎和现有的关系数据进行 Join 等计算。
图 2：异构数据无缝转换&计算
（二）融合存储的价值
图 3：结构化&半结构化数据存储降本
举个例子，考虑用户在高德地图上显示的轨迹，每个时间段内都会采集一个点，这些点组成了轨迹，而这些轨迹就相当于一个 double 对(分别表示经纬度)的数组。数据库可以很容易地压缩单一 double 类型的数据，但是轨迹这种基于 double 对和变长数组嵌套组成的半结构化数据的压缩就相对困难许多。但是如果把轨迹数组拆解成两个普通 double 数组，就可以复用 OceanBase 已有的 double 编码技术，极大提升轨迹数据的压缩比。在 OceanBase 中，我们正是通过提取半结构化数据的结构特征的方式，再复用 OceanBase 已有的数据编码技术，解决半结构化数据编码压缩的问题。
三、聊聊OBKV的两款NoSQL模型
目前 OBKV 已经支持两款 NoSQL 相关的模型，即 OBKV-HBase 和 OBKV-Redis。
（一）OBKV-HBase
HBase 在大数据处理中的优缺点
适用场景对比
对于普通的 HBase 场景，OceanBase 的 OBKV-HBase 可以轻松胜任，并且提供相比 HBase 更高的性能。对于结构化场景，也可以使用 OBSQL，通过索引和灵活的算子，不仅带来数倍的压缩率，还能够为用户提供更大的灵活性。
图 4：OBSQL & OBKV-HBase 覆盖 HBase 生态场景
HBase 替换场景
在 OceanBase 替换 HBase 的实际场景中，下面左图展示了贝壳的情况。贝壳案例主要在 Flink 中进行 ETL，将复杂的字符串转换为 ID，在下游基于 ID 进行分析，返回数据时，替换 ID 和字符串。挑战在于，Flink 中的流式计算需要频繁访问字典服务，因此字典服务需要具有非常低的时延和非常高的吞吐量。使用 OceanBase 的 SQL，数据处理将会变得非常简单。
右图仟传的场景稍微复杂一些。原始数据经过 Kafka 流到 Flink，Flink 会对用户数据和事件数据进行分析，如果用户数据不完整，Flink 会补全并插入数据库。由于事件数据本身是一个嵌套结构，有可能在一个事件数据中引用另一个事件，Flink 在获取事件后，会重新关联事件并补全，然后传递给下游。在这种情况下，OceanBase 具备处理海量数据存储和极致读写能力的优势。
图 5：OceanBase HBase 替换场景
（二）OBKV-Redis
兼容 Redis 接口的持久化数据库
Redis 在极致 RT 和高吞吐率的场景下表现出色，比如在广告、游戏等现金流业务中，需要与 Redis 进行多次交互的情况下，业务的访问延迟直接影响到收入。然而，在我们和用户的交流中收到很多类似的反馈，在传统的 RDS 和 Redis 组合场景中，成本较高，业务架构复杂，因为业务不仅需要感知 Redis，还需要感知 RDS，并且需要关注它们之间的一致性。同时，通用的解决方案放在业务层并不合适，大多数场景并不需要 200-500 微秒的实时延迟。我们进行了一组数据测试，如下图所示。将 OceanBase 的延迟控制在 1 毫秒内，在不同数据量的情况下观察整个数据库的吞吐情况，最终结果仍然是令人满意的。
图 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 运维工作所需的人力成本，以及对技术体系的要求。
四、写在最后
正如我们在文章中所介绍的，OceanBase 的多模能力使得用户无需为不同类型的数据部署不同的数据库，只需使用一个数据库、一个引擎即可。OceanBase 原生支持多种数据模型，包括 SQL 和 NoSQL，为用户提供了根据自身需求选择合适数据模型的便利。
近期发布的 OceanBase 4.2.3 版本针对多行批量操作和单行操作的性能进行了深度优化，该特性也会更新到 4.3.3 版本。相较于之前的版本，OBKV 在单行读写性能上提升了约 70%，批量读写性能提升了 80-220%。
