《一文讲透》第6期:揭秘 KWDB 的多模核心技术
引言:当时间序列遇见关系模型
在工业物联网监控场景中,每分钟即可产生百万级的传感器时序数据,同时需要关联设备元数据表进行实时分析;在金融交易系统中,每秒数万笔交易流水需要与账户关系表进行 ACID 事务处理;在车联网平台系统中,特殊车辆的产生的大量定位信息,在查询中需要定位信息需要关联车辆的静态数据信息进行检索。
这种时序数据与关系数据的交织处理需求,正在催生新一代多模数据库的崛起。本文将深入探讨在这类特定场景下,多模数据库的核心技术究竟是如何实现的。
KWDB 多模融合架构设计
我们在数据库的核心模块改造了多模 SQL 解析器,多模 SQL 优化器,多模 SQL 执行器,并优化了自适应查询。
多模架构设计思路
以物联网场景为例,因设备产生的数据通常具有时间戳,如传感器读数、设备状态等,数据管理通常以时序数据为核心。然而,物联网系统不仅限于时序数据,还包括设备元数据、用户信息、日志记录等非时序数据。这些数据同样重要,广泛应用于设备管理、用户交互和系统维护。因此,在物联网业务场景下,市面上存在以下非多模方案:
-
关系数据存储在 MySQL 等的关系数据库中,时序数据存储在 InfluxDB 等时序数据库中,在进行关联查询时在数据中台将两部分数据汇总后进行关联查询,这种跨库的数据关联会产生极大的查询性能延迟。
-
时序数据库保存部分关系数据,使得关系数据和时序数据保存在一起,再采用优化手段,降低关系数据带来的冗余存储,这样虽然能提高部分关联查询的速度,但是由于关系数据和时序数据存储的特性,其无法支撑复杂的跨模关联的查询,也无法适应原有关系数据和新增时序数据的结合。
KWDB 的多模方案是将关系数据和时序数据统一管理,采用自适应数据存储和查询的方案。
根据不同模的数据的存储特性采用特定的存储方案,关系数据保存在关系存储引擎中,时序数据保存在时序存储引擎中,如此时序数据即可实现特定的存储优化,自带时间索引、设备索引等。
多模数据管理
用户进行查询时,根据查询的库表进行自适应的查询模式鉴别,通过统一的查询优化器,针对时序和关系的数据做特定的查询优化,生成统一的逻辑计划,最终根据查询的数据模不同定制不同的物理查询计划和物理计划优化。非跨模数据可以在就地计算完成后直接反馈给客户端,跨模关联计划则需要将多模的计算结果汇总后反馈给客户端。
多模查询优化
技术要点
多模解析器
KWDB 数据库采用多模元数据统一管理模式,时序数据保存在 ts database 中,根据 database 的标记来区分时序和关系数据。针对时序数据的库标记来进行时序数据的管理,比如有些数据类型是时序数据不支持的(例如 decimal)。时序数据的查询函数限制等出现的位置有限定。例如:
sql -- 创建时序数据库db_pipec CREATE TS DATABASE db_pipec; -- TS table CREATE TABLE db_pipec.t_point ( k_timestamp timestamp NOT NULL, measure_value double ) ATTRIBUTES ( point_sn varchar(64) NOT NULL, sub_com_sn varchar(32), work_area_sn varchar(16), station_sn varchar(16), pipeline_sn varchar(16) not null, measure_type smallint, measure_location varchar(64)) PRIMARY TAGS (point_sn) ACTIVETIME 3h;
根据不同模的标记进行针对性的解析和编译,我们会根据时序数据的特性,针对性地增加和限制部分功能在时序数据的使用上,比如针对时序数据支持的特殊函数会在解析时进行判断,如果在关系数据中使用就会触发报错。
多模优化器
多模优化器会统一处理所有查询的优化,遇到针对时序的查询会充分利用时序数据的特点有针对性的优化 。在优化之后还会针对时序数据不支持的算子和计算进行深度优化,将时序数据不支持的算子和计算放到关系执行器部分进行计算,时序计算完成后在关系执行器再次进行计算,保证查询的完整性。
• 跨模查询会根据时序和关系表的关联查询进行数据进行评估,根据代价评估来决定数据的流转方向,提高数据流转的效率。同时通过对时序数据计算进行优化以提高查询效率。
• 单独的时序数据查询会使用时序特有的优化技术,采用多种优化策略,如时序索引(primary tag 索引,时间范围索引等)、算子下推、统计信息应用、聚合下推等多种手段提高时序数据的查询效率。
多模执行器
时序执行器和关系执行器通过抽象成统一的执行接口进行管理,针对一套逻辑计划进行多模执行的封装。给时序数据的执行定制一套专用的执行器,根据时序数据的存储结构定制执行计划。时序数据通常会根据不同的设备、时间范围、设备信息进行检索,因此执行器充分利用 primary tag 索引、时间范围索引、tag 索引做定制化的执行。
例如首先会根据查询的 primary tag 从存储的 tag 结构中获取 tag 的数据,然后查询到此 tag 对应的时序数据部分的内容,拿到整体的数据后进行 merge,输出为一条完整的数据传递给上层进行计算处理。
时序数据处理时会有选择性优化,比如关系数据和时序数据进行关联查询时:
-
如果关系数据的过滤性高并且关系数据和时序数据关联的条件中使用的是时序的 tag 值,则会选择将关系的数据下推到时序引擎端进行计算,优化的计算方式可以是直接 hash 过滤 tag 数据,还可以是 look up tag 数据,以此来提高时序数据的检索效率,提前过滤掉时序的大部分数据,减少跨模传递的数据量。我们称这种优化的方式为 outside-in 优化。
-
如果关系数据没有过滤,并且在关联查询后进行了聚合计算,那么可以选择将聚合计算下推到时序引擎进行计算,来提前聚合时序数据,以达到减少时序部分数据量的效果,减少跨模传递的数据量。我们称这种优化的方式为 inside-out 优化。
回归业务本质的数据架构
多模数据库不是简单的技术堆砌,而是面向真实业务场景的架构革新。通过深度整合两种广泛使用的数据模型,它既保留了关系数据库强大的结构化处理能力,又具备了时序数据库的海量吞吐优势,这种融合架构也正在工业物联网、金融科技、车联网等领域展现出强大的生命力,也标志着数据库技术进入垂直深度优化的新阶段。
最后,如果大家对多模感兴趣,欢迎在 Gitee 检索“KWDB” ,体验我们的项目并参与互动。
不管是操作疑问、功能需求或是其他疑问,大家都可在 Gitee 提交 Issue,欢迎一起共建更完善的 KWDB 生态。
Gitee 链接合集
→ 下载安装包:
https://gitee.com/kwdb/kwdb/releases
→ 开发文档:
https://gitee.com/kwdb/docs
→ KWDB 仓库:
https://gitee.com/kwdb/kwdb
(扫码直达 Gitee)
往期推荐:
KaiwuDB 魏可伟:用“多模”实现对行业的“One size best fits”
KaiwuDB CTO 魏可伟:差异化创新,面向行业的多模架构
KaiwuDB CTO 魏可伟:多模架构 —“化繁为简”加速器

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
分布式数据一致性场景与方案处理分析|得物技术
一、引言 在经典的CAP理论中一致性是指分布式或多副本系统中数据在任一时刻均保持逻辑与物理状态的统一,这是确保业务逻辑正确性和系统可靠性的核心要素。在单体应用单一数据库中可以直接通过本地事务(ACID)保证数据的强一致性。 然而随着微服务架构的普及和业务场景的复杂化,原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题,但业务实际又需要保障一致性,为此BASE理论提出了最终一致性来解决这类问题。那么如何在跨服务、跨数据库的事务中保证数据最终一致性。 二、CAP理论与BASE理论 在经典的CAP理论中提到一个分布式系统中,一致性(C)、可用性(A)、分区容错性(P)最多只能同时实现两点,不可能三者兼顾。实际上这是一个伪命题,必须从 A 和 C 选择一个和 P 组合,更进一步基本上都会选择 A,相比一致性,系统一旦不可用或不可靠都可能会造成整个站点崩溃,所以一般都会选择 AP。 BASE理论源于对大规模互联网分布式系统实践的总结,作为CAP定理中一致性与可用性矛盾的实践性补充逐步演化形成。该理论主张在无法保证强一致性的场景下,系统可基于业务特性灵活调整架构设计,通过基本可用性保...
- 下一篇
淘宝客户端动态化页面搭建
在手机淘宝等高频更新的业务场景中,UI页面的动态化和快速交付成为技术团队面临的重要挑战。本文围绕“客户端动态化页面搭建”这一主题,深入探讨了如何通过抽象框架设计解决高动态化页面的快速构建问题。文章详细介绍了框架的核心模块(如DataEngine、LayoutEngine、StateCenter等)、页面动态性实现方式、组件通信机制以及业务接入流程,并结合实际案例分析了布局方式多样性的问题及解决方案。最终总结了该框架在动态性、拓展性和能力沉淀方面的优势,为类似业务场景提供了宝贵的实践经验。 背景 手机淘宝详情一直是一个页面UI更新频率较高的业务场景,对于UI元素变更有快速交付的要求。接手行业相关的需求后,发现行业相关的UI更是如此,行业每个业务UI各不一样,但布局逻辑大致相同。针对上述背景,我们希望能有一个对于高动态化页面快速搭建的解决方案。 问题 当业务由于某些原因需要对渲染协议进行升级的时候,端侧就会产生一个全新的版本,比如详情1.0、2.0、行业化等等。虽然页面整体布局方式大致一致,但是各个版本之间的代码基本是割裂的,如果需要升级协议,每次的工作量都是巨大,而且切流过程也是比较复杂...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS8编译安装MySQL8.0.19
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16