深圳公司免费网站建设怎么样,室内设计优秀作品,网页设计入门书,深圳短视频seo教程在当今多元化的业务生态中#xff0c;各行各业对数据库系统的需求各有侧重。举例来说#xff0c;金融风控领域对数据库的高效事务处理#xff08;TP#xff09;和分析处理#xff08;AP#xff09;能力有着严格要求#xff1b;游戏行业则更加注重文档数据库的灵活性和性…在当今多元化的业务生态中各行各业对数据库系统的需求各有侧重。举例来说金融风控领域对数据库的高效事务处理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 引擎中以便更好地满足用户的使用习惯和业务需求。 图 1OceanBase 多模融合一体化引擎
另外用户在大数据分析场景里使用 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 函数等能力)将结果聚合成相应的数据返回给业务。 图 2异构数据无缝转换计算
二融合存储的价值
在半结构化数据中实现编码的工程难度非常大因为数据本身的结构化程度不高市面上大多数数据库产品也没有对 JSON 数据做压缩编码只是按照文本或者二进制的方式简单存储。OceanBase 可以更好地解决这一问题而且OceanBase 的编码能力与 MySQL 等数据库相比有着数量级的降本优势。 图 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通过索引和灵活的算子不仅带来数倍的压缩率还能够为用户提供更大的灵活性。 图 4OBSQL OBKV-HBase 覆盖 HBase 生态场景 ○ HBase 替换场景
在 OceanBase 替换 HBase 的实际场景中下面左图展示了贝壳的情况。贝壳案例主要在 Flink 中进行 ETL将复杂的字符串转换为 ID在下游基于 ID 进行分析返回数据时替换 ID 和字符串。挑战在于Flink 中的流式计算需要频繁访问字典服务因此字典服务需要具有非常低的时延和非常高的吞吐量。使用 OceanBase 的 SQL数据处理将会变得非常简单。
右图仟传的场景稍微复杂一些。原始数据经过 Kafka 流到 FlinkFlink 会对用户数据和事件数据进行分析如果用户数据不完整Flink 会补全并插入数据库。由于事件数据本身是一个嵌套结构有可能在一个事件数据中引用另一个事件Flink 在获取事件后会重新关联事件并补全然后传递给下游。在这种情况下OceanBase 具备处理海量数据存储和极致读写能力的优势。 图 5OceanBase HBase 替换场景 二OBKV-Redis
○ 兼容 Redis 接口的持久化数据库
Redis 在极致 RT 和高吞吐率的场景下表现出色比如在广告、游戏等现金流业务中需要与 Redis 进行多次交互的情况下业务的访问延迟直接影响到收入。然而在我们和用户的交流中收到很多类似的反馈在传统的 RDS 和 Redis 组合场景中成本较高业务架构复杂因为业务不仅需要感知 Redis还需要感知 RDS并且需要关注它们之间的一致性。同时通用的解决方案放在业务层并不合适大多数场景并不需要 200-500 微秒的实时延迟。我们进行了一组数据测试如下图所示。将 OceanBase 的延迟控制在 1 毫秒内在不同数据量的情况下观察整个数据库的吞吐情况最终结果仍然是令人满意的。 图 6OBKV-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%。
此外OceanBase 的多模文档已经正式上线您可以查看文档获取更多信息。我们也欢迎您试用 OceanBase 的多模能力并给我们提供反馈。
