当前位置：首页 > news >正文

OpenClaw+Docker+KWDB3.1

news 2026/3/26 21:20:45

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

业务场景背景

我刚工作的时候做了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;

看到这里可能大家说这个像PG啊。是不是基于PG？答：不是。但是对PG的语法兼容度好。
看一下数据样本。还挺像我以前公安时候的数据。
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中完成了关联查询。这是非常重要的，即在时序数据库中可以关联查询。这不是所有时序数据库都可以的。这就是我要的结果。

查看全文

http://www.jsqmd.com/news/483946/