OpenClaw+Docker+KWDB3.1

KaiwuDB 3.1.0 社区版发布

• 作为KWDB的MVP怎么说也要体验和支持一下。
• KWDB具备千万级设备接入、百万级数据秒级写入、亿级数据秒级读取等时序数据高效处理能力，具有稳定安全、高可用、易运维等特点。面向工业物联网、数字能源、车联网、智慧产业等领域，提供一站式数据存储、管理与分析的基座。
• KWDB 3.1.0 版本在保持原有特性的基础上，针对数据库对象、数据写入与查询、数据库运维与安全、数据库稳定性、数据库性能等进行了全面优化与增强。

为什么要多模态

• 之前在KWDB3.0的发布会上，我主持了圆桌。那是2025年11月。才过了3个月，小版本就更新了。对于3.0当时的理解是在原有时序数据库上的多模态增强。我记得当时我们讨论，为什么要在时序数据库中支持关系型的模态。因为单一的时序数据库几乎都能满足物联网场景的应用。但是设备的信息可能在关系型数据库表中。需要这样的关联。
• 我曾经的一个选型失败案例就是单一的时序数据库，数据没有打通其实最后没有达到业务需求。业务拿到了所有的数据，但是他想知道经过传感器上的物品是否缺失和丢失。但是最终无法比较，因为这些重量和件数的数据存在订单表上。这是两个异构数据库。

最近OpenClaw很火，我就用他来完成这次体验

• 因为我小龙虾环境有docker，所以我希望用docker来部署。
• 从社区拿到了链接 registry.cn-hangzhou.aliyuncs.com/kwdb/kwdb:3.1.0

image.png

• 小龙虾执行指令性的工作勉强可以。省去了我一些麻烦。他直接给我启动了。
• 让他给我初始化数据

image.png

业务场景背景

image.png

• 我刚工作的时候做了12年的公安、安防行业。大家在路上开车，经过路口或者路段闪光灯闪一下。然后其实就是被拍照了。图片和记录马上存到数据中心，进入数据库。这种在一个省级平台来说10几年前大约能有5000多个监控点、一个省有300万机动车都是很正常的。一天新增6000万到1亿数据很正常。3个月就能有100亿。
• 这种场景我们以前是用Oracle做的。有的甚至是单机。但是还不知道有时序数据库。用时序数据库做也不是不可以。至少比用kafka+OLAP数据库的解决方案要好。因为这还多了一个技术栈和环境。我一直崇尚简约的架构。

测试体验

• 脚本也是OpenClaw生成的：
• – 清空旧表 DROP TABLE IF EXISTS traffic_flow; DROP TABLE IF EXISTS monitor_location; DROP TABLE IF EXISTS vehicle_info;

– 建表（已删除所有外键！） CREATE TABLE monitor_location ( id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, city VARCHAR(50) NOT NULL, district VARCHAR(50) NOT NULL, latitude DECIMAL(9,6), longitude DECIMAL(9,6), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

CREATE TABLE vehicle_info ( id SERIAL PRIMARY KEY, plate_no VARCHAR(20) NOT NULL UNIQUE, vehicle_type VARCHAR(20), register_date DATE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

CREATE TABLE traffic_flow ( id BIGSERIAL PRIMARY KEY, vehicle_id INT NOT NULL, location_id INT NOT NULL, pass_time TIMESTAMP NOT NULL, speed DECIMAL(5,2), direction VARCHAR(10) );

– 索引 CREATE INDEX idx_traffic_flow_vehicle_id ON traffic_flow(vehicle_id); CREATE INDEX idx_traffic_flow_location_id ON traffic_flow(location_id); CREATE INDEX idx_traffic_flow_pass_time ON traffic_flow(pass_time);

– 1万监控点 INSERT INTO monitor_location (name, city, district, latitude, longitude) SELECT ‘monitor’,‘北京’,‘朝阳’, round((random()*40+20)::numeric,6), round((random()*50+70)::numeric,6) FROM generate_series(1,10000) AS i;

– 10万车辆 INSERT INTO vehicle_info (plate_no, vehicle_type, register_date) SELECT ‘VN’||CAST(i AS VARCHAR),‘小型车’,‘2020-01-01’ FROM generate_series(1,100000) AS i;

– 100万过车流水（无任何外键，绝对不报错） INSERT INTO traffic_flow (vehicle_id, location_id, pass_time, speed, direction) SELECT (i % 100000) + 1, (i % 10000) + 1, CAST(‘2025-01-01 00:00:00’ AS TIMESTAMP) + (i%1000) * INTERVAL ‘1 second’, round((random()*60+20)::numeric,2), ‘东’ FROM generate_series(1,1000000) AS i;

image.png

• 看到这里可能大家说这个像PG啊。是不是基于PG？答：不是。但是对PG的语法兼容度好。
• 看一下数据样本。还挺像我以前公安时候的数据。

image.png

• select t.plate_no,v.vehicle_type,t.device_code,pass_time,city,district from traffic_flow t,monitor_location m,vehicle_info v where t.plate_no=v.plate_no and t.device_code=m.device_code limit 10;
• 最终在一个SQL中完成了关联查询。这是非常重要的，即在时序数据库中可以关联查询。这不是所有时序数据库都可以的。这就是我要的结果。

image.png