KaiwuDB 数据库

而且这套“组合拳”，基于就地计算、流式计算等核心技术，支持多层级、多维度数据下钻等各项功能，能够对物联网设备产出的海量数据进行实时统计与分析，为管理层提供科学管理决策依据，进而优化企业生产流程，提高企业生产效率，最终实现降本增效。凭借海量时序数据高吞吐率写入、批量高速复杂查询与多维聚合、高稳定性与高安全性、高数据压缩比、支持主流多类型编程语言、统一运管低成本运维、多平台支持&集群管理&云边协同 7 大核心功能，KaiwuDB 帮助用户在实际业务场景下，有效摆脱上述面临的现实困境。

就在上月，国际权威数据库性能测试榜单 benchANT 更新了 Time Series: Devops（时序数据库）场景排名，KaiwuDB 数据库在 xsmall 和 small 两类规格下的时序数据写入吞吐、查询吞吐、查询延迟、成本效益等多项指标刷新榜单原有数据纪录。

KaiwuDB CTO 魏可伟受邀于 2024 可信数据库发展大会主论坛发表演讲《多模一库 —— KaiwuDB 的现代数据库架构探索》，KaiwuDB 2.0 版本全新发布

对于 DBA，需清晰明确不同数据库的运维规则，开发运维成本高；作为业内首款“面向 AIoT 的分布式多模数据库”产品，KaiwuDB 基于统一的 SQL 语法、统一的数据库命令、统一的开发运维工具、统一的安全认证等实现真正。这就使得企业对数据库的需求不光停留在一款性能优异的时序数据库上，而是同时要求数据库具备包括事务分析引擎等在内的不同引擎能力，支撑在线交易、数据分析等。— 包括软硬件的融合、计算模型的融合、存储模型的融合，从而加速数据价值化、提升用户数据消费能力，是当今数据库亟需解决的一大命题。

在人工智能技术飞速发展的当下，大模型已成为推动产业变革的核心力量，但其高昂的研发成本与落地挑战却让众多企业望而却步。除了资金投入，模型训练还面临数据质量要求高、模态结构复杂、算力消耗大、耗时久等多重难题，这些都成为企业入局大模型的 “高门槛”。2016-2023 年部分人工智能模型训练成本估算（图片来源于网络）成本压力之下，企业 AI 工程化落地率同样不容乐观。麦肯锡调研数据显示，仅有 1% 的受访企业认为他们的 AI 投资已经达到成熟阶段。

DTCC 2024 期间，KaiwuDB CTO 魏可伟老师受邀接受知乎数据库负责人代晓磊的采访，内容十分干货

未来，不管是多模数据库本身的发展，还是与 AI 的结合，KaiwuDB 都将坚持回归用户本位，专注于打造一款“小而全”的数据库产品。在面对国内外用户对于产品性能与产品性价比“既要又要”的挑战下，KaiwuDB 也将不忘初心，秉承“匠心”精神走出自己的新路子，给市场与用户带来更多的可能。

举个例子，企业要存工厂设备类型信息（关系型）以及工厂各类设备（如拧紧机等）采集的数据（时序型），如果用 2 个独立数据库，会面临数据孤岛、跨库查询复杂、维护成本高的问题。而 KaiwuDB 作为国内面向物联网 AIoT 场景的分布式多模数据库代表，能够支持在同一实例同时创建时序库和关系库，融合处理包括结构化数据、非结构化数据在内的多模数据。：提供 Agent 智能体工具，借助 MCP 协议，结合 LLM 技术，将自然语言处理与 KaiwuDB 深度结合，赋能数据库自动化运维与智能管理。

综上，KaiwuDB 分布式执行引擎通过一系列核心优化举措，系统性破解了传统架构的多重瓶颈，构建起高效、稳定、可扩展的分布式执行体系，为高并发、大规模时序数据及多模数据分析业务提供了坚实的技术支撑。明确管理节点（ME）的调度职责、根执行节点的结果汇总职责及普通执行节点的计算职责边界，降低模块间耦合度，可快速定位问题节点及流水线阶段（Stage），提升 Debug 的效率与精准性。：在执行节点节点间构建专用通信链路，采用与本地算子同源的数据格式传输中间结果，彻底消除节点间的数据转换开销。

KaiwuDB V3.0技术合集摘要：本文汇总了KaiwuDB V3.0企业版的核心技术文章，涵盖多模架构（统一管理关系/时序数据）、跨模查询优化（性能提升279倍）、分布式执行引擎（Pipeline架构/统一编码）、时序存储（列式存储/三层结构）、流计算（实时处理）、数据分发（CDC捕获）以及智能运维（KAT智能体工具）等方向。特别介绍了AI赋能的时序基础模型AGREE原则和智能运维方案。面向企业级用户提供技术解析，帮助快速了解KaiwuDB V3.0的技术体系。可通过官网获取完整文档和社区支持。（149

的理念，设计了开箱即用的订阅发布能力：无需用户开发复杂的自定义同步逻辑，通过配置化的方式即可实现跨集群、跨系统的数据实时同步，同时兼容多种技术生态（时序引擎、消息队列、业务应用），让不同业务场景能快速复用该能力。其核心目的在于，确保需要数据的人或系统能够在正确的时间、以恰当的形式获取到准确的数据，实现数据的共享与同步。KaiwuDB 数据分发以**“数据价值最大化”**为核心设计原则，在源端与多目标端之间搭建高效、灵活、可靠的流转桥梁，以最小化传输带宽、时间成本实现最大传输效率，发挥最大数据价值。

流计算是面向流式数据的计算，即对持续不断产生的数据流进行实时采集、处理、分析与输出，最终将处理结果写入目标表。流计算的核心是 “边产生数据边处理”，而非等待数据全部存储后再批量计算。因此，流计算的一大关键优势就是——能够极大地缩短从数据产生到获取洞察之间的时间，在更短时间内挖掘数据价值。

介绍了KaiwuDB 3.2.x版本的时序存储引擎架构设计。作为开源分布式数据库，KaiwuDB针对AIoT场景的时序数据特点，采用列式存储和内存映射技术优化性能。存储结构分为元数据、数据文件（LastSegment和EntitySegment）和WAL日志三部分，通过VGroup哈希分区和时间分区实现高效管理。文章详细解析了数据文件组织方式，包括内存刷盘生成的LastSegment和合并生成的EntitySegment文件组，以及其索引机制。该设计在保证数据一致性的同时，显著提升了时序数据的写入和查询效率

本文系统梳理了 KWDB 在查询编译与优化方面的核心流程，包括 SQL 语句的词法解析、语法解析、语义解析，以及基于规则的 RBO 优化、基于成本的 CBO 优化，同时详细介绍了针对多模场景的计算本地化优化策略。其核心目标是找到时序引擎能够支持的最大计划树，确保尽可能多的计算逻辑在时序引擎中完成。：核心作用是基于规则与成本优化策略，对解析器生成的结构化数据进行等价转换，在不改变 SQL 语句原意的前提下，提升执行效率、降低运行成本，主要涵盖 RBO 优化、CBO 优化和多模计算优化等方式。

在物联网、工业互联网、智慧城市等领域飞速发展的今天，时序数据已成为刻画物质世界演化的核心语言。从工业设备的温度、压力监测，到气象领域的降雨量变化，再到医疗场景的心电图波形，时序数据无处不在且量级巨大，蕴藏着驱动决策的重要价值。然而，时序数据分析面临开发代价高、周期长、维护成本大、通用性不足等痛点，因此，如何降低各领域使用时序人工智能的门槛，促进物联网企业 AI 工程化落地是亟待攻克的一大关键课题。KaiwuDB 联合华东师范大学重磅推出的时序基础模型，以"治理-分析-决策"为核心框架，秉持AGREE（

在 AIoT、工业互联网场景中，类似"设备元数据（关系数据）+ 传感器数据（时序数据）"这样的联合查询是业务的重要需求之一。然而，在传统多库架构下，这类跨模查询往往意味着 “数据迁移 + 小时级等待”。KaiwuDB 创新自研的跨模优化技术，可将原本可能需要 5 小时的查询任务压缩至 64 秒，场景性能甚至能实现百倍的飞跃。今天就带大家一同探秘，深度拆解 KaiwuDB 跨模查询性能飞跃的核心技术。百倍级别的性能提升，绝非 “简单调优” 能实现。其背后的密码是------KaiwuDB 通过。

这些设备以极高的采样频率持续产生监测数据，使得单条产线每秒产生数十万条传感器数据已成为行业常态，这对数据存储系统的写入吞吐量和查询响应时间提出了前所未有的挑战。面对如此海量时序数据的实时写入与高效查询需求，传统的关系型数据库和通用型NoSQL数据库往往显得力不从心，本文则将聚焦 KWDB 中独具特色的标签（Tag）机制及其索引优化策略，揭示如何通过合理设计提升时序数据管理效率。其中时间戳记录数据产生时刻，字段列存储动态变化的监测数值，而标签列则承载设备的静态属性。√ 选择离散值高的字段（如自增 ID）

• 如果关系数据的过滤性高并且关系数据和时序数据关联的条件中使用的是时序的 tag 值，则会选择将关系的数据下推到时序引擎端进行计算，优化的计算方式可以是直接 hash 过滤 tag 数据，还可以是 look up tag 数据，以此来提高时序数据的检索效率，提前过滤掉时序的大部分数据，减少跨模传递的数据量。用户进行查询时，根据查询的库表进行自适应的查询模式鉴别，通过统一的查询优化器，针对时序和关系的数据做特定的查询优化，生成统一的逻辑计划，最终根据查询的数据模不同定制不同的物理查询计划和物理计划优化。

KWDB 的分布式元数据管理采用的统一的数据管理方式，所有的系统数据统一划分为相同大小的分片 Range，使用两级路由的方式管理元数据，每条路由元数据约为 256B，单个元数据 Range 可存储 256K 条路由信息（64MB/256B），所有 ME 启动就持有 Root Mata Range，通过改 Root Mata Range 可以路由到 Metadata Range 以及 User Range。KWDB 为支持这种跨模的执行，增加 ME 层到 AE 层数据下推通道用以支持不同模之间的数据交互。

KWDB 采用预写式日志（Write-Ahead Logging，WAL），记录每个时序表的模式变更和数据变更，以实现时序数据库的数据灾难恢复、时序数据的一致性和原子性。KWDB 默认会将保存在 WAL 日志缓存中的日志条目实时写入日志文件，每5分钟通过后台线程更新 WAL 文件和数据文件的 CHECKPOINT_LSN (检查点日志序列号)，写入 CHECKPOINT WAL 日志，然后同步数据文件到磁盘。系统正常停机时，KWDB 会主动同步数据文件到磁盘并更新 CHECKPOINT_LSN。

KWDB 数据库可高效处理海量且连续的数据流，但对于运维人员来说，根据业务需求进行硬件规划是确保系统稳定、高效运行的基础。

数据分布在数据库中的作用至关重要，它直接影响到数据库系统的性能、可扩展性、可用性、管理效率和成本。特别是在处理海量数据和高并发请求的现代应用中，合理的数据分布策略是数据库架构设计的核心。本期直播重点讲解了数据分布在分布式数据库中的重要性、 KWDB 数据库分布式架构设计方案、特性及具体实践案例。• Hash 适合预分片，系统会更具确定性；Range 更依赖调度系统• Range 对范围查询很友好，Hash 范围查询基本等价于全表扫描• Range 对前缀查询很友好，实际上属于一种范围查询。

如果服务器不支持客户端请求的次要版本（例如，客户端请求版本为 3.1，但服务器仅支持 3.0，不支持 3.1 版本，此时就会发生这种情况），则服务器可以拒绝连接，或者可以使用包含其支持的最高次要协议版本的 NegotiateProtocolVersion 消息进行响应。需要注意的是，服务器可以返回的字符串长度没有预定义长度的限制，因此客户端比较好的编码策略是使用可扩展缓冲区，以便可以接收适合内存大小的内容。需要注意的是，由于历史原因，客户端发送的第一条消息（启动消息）没有消息类型的 1 个字节。