如题,新手接触 TimescaleDB ,目前是用这套方案做了一套存音频传感器的数据的工具,大概有 100 个左右的传感器,存二进制数据,日增大概十万行左右。
目前遇到比较大一个问题是,常见的搜索场景是“搜索传感器 A 在某月某日到某月某日期间的所有记录”。但是目前搜索优化器是先从时间的总序列开始查,然后再筛选其中的 A 传感器。而我觉得逻辑上显然是先搜索 A 传感器再筛选时间更优。
前者不光是慢的问题,而且现在有个大问题是走时间索引的话,每个操作占用锁的数量太多了,就算把参数调大了,日常使用也经常报错。
问下万能的 v2 ,有什么办法解决吗?
附: 创建表的命令:
CREATE TABLE sensor_data (
ts TIMESTAMPTZ NOT NULL,
sensor_id INTEGER NOT NULL,
data VARCHAR(64) NOT NULL,
PRIMARY KEY (sensor_id, ts)
);
SELECT create_hypertable(
'sensor_data',
'ts',
partitioning_column => 'sensor_id',
number_partitions => 16,
chunk_time_interval => INTERVAL '7 day'
);
解释搜索命令得到如下结果:
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM sensor_data
WHERE sensor_id = '001'
AND ts >= '2024-12-06 00:00:00+08'::timestamptz
AND ts < '2024-12-07 00:00:00+08'::timestamptz;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using _hyper_3_23024_chunk_sensor_data_ts_idx on _hyper_3_23024_chunk (cost=0.28..6.71 rows=144 width=45) (actual time=0.032..0.062 rows=144 loops=1)
Index Cond: ((ts >= '2024-12-06 00:00:00+08'::timestamp with time zone) AND (ts < '2024-12-07 00:00:00+08'::timestamp with time zone))
Filter: (sensor_id = 1)
Buffers: shared hit=6
Planning:
Buffers: shared hit=1076 read=1
Planning Time: 7.689 ms
Execution Time: 11.201 ms
(8 rows)
如各位所见的就是不管怎么调,一开始都是走 ts_idx 索引,然后再 filter sensor_id
感觉 timescaleDB 是个好东西,但是这个问题卡住完全没法用啊。拜谢各位
1
siaronwang 54 分钟前
pg 应该已经安装 sensor_id 找到了 hyper_3_23024_chunk 块,执行计划的成本优化导致的选择吧。而且这个查询 sensor_id 是字符串,你 sensor_id INTEGER NOT NULL, 这里是 integer 是不是导致索引失效了呢。
|
2
siaronwang 53 分钟前
另外可以创建一个针对`CREATE INDEX ON sensor_data (sensor_id, ts DESC);` 这样索引 可以试试
|