时间戳

首页 > 解决方案 > Clickhouse 似乎很慢

database - Clickhouse 似乎很慢

问题描述

我们正在考虑将 ClickHouse 用作物联网使用的时间序列数据库，因此我们遵循了创建为此设计的表的最佳实践，但是在运行测试时，第一次运行查询时结果似乎很慢，但是它很快（由于冷缓存）。

我们的表模式如下：

CREATE TABLE IF NOT EXISTS feeds (
    ts UInt64,
    uuid UUID,
    value Decimal(30, 5),

    date Date MATERIALIZED toDate(round(ts/1000)) CODEC(DoubleDelta),
    time DateTime MATERIALIZED toDateTime(round(ts/1000)) CODEC(DoubleDelta)
  ) ENGINE = ReplacingMergeTree() PARTITION BY toYYYYMM(date) PRIMARY KEY (uuid, ts) ORDER BY (uuid, ts) SETTINGS index_granularity=4096

然后查询，我们执行这个：

 SELECT toStartOfInterval(time, INTERVAL '1 day') AS agreg,
        avg(value) AS value
 FROM feeds
WHERE uuid='391becbb-39fd-4205-aba1-5088c9529d42'
  AND ts > 1629378660000
  AND ts < 1632057060000
GROUP BY agreg
ORDER BY agreg ASC

这代表了大约一个月的数据，每天汇总。

我们得到这个结果：

┌───────────────agreg─┬──────────────value─┐
│ 2021-08-19 00:00:00 │  43.54795698924731 │
│ 2021-08-20 00:00:00 │  33.68460122699386 │
│ 2021-08-23 00:00:00 │   26.8002874251497 │
│ 2021-08-24 00:00:00 │  45.30143348623853 │
│ 2021-08-25 00:00:00 │  43.78214139344263 │
│ 2021-08-26 00:00:00 │  35.66887477313974 │
│ 2021-08-27 00:00:00 │  87.03632541133456 │
│ 2021-08-28 00:00:00 │  87.00372191011236 │
│ 2021-08-29 00:00:00 │  87.16366666666666 │
│ 2021-08-30 00:00:00 │  87.62234215885947 │
│ 2021-08-31 00:00:00 │  87.62653798256538 │
│ 2021-09-01 00:00:00 │  87.08854251012146 │
│ 2021-09-02 00:00:00 │ 44.809177939646204 │
│ 2021-09-03 00:00:00 │  20.85095168374817 │
│ 2021-09-06 00:00:00 │ 21.086067551266584 │
│ 2021-09-07 00:00:00 │ 20.904265569917744 │
│ 2021-09-08 00:00:00 │ 20.988032407407406 │
│ 2021-09-09 00:00:00 │ 21.070418848167538 │
│ 2021-09-10 00:00:00 │ 20.900507674144038 │
│ 2021-09-14 00:00:00 │  34.17651296829971 │
│ 2021-09-15 00:00:00 │  33.79448634590377 │
│ 2021-09-16 00:00:00 │   33.7209536423841 │
│ 2021-09-17 00:00:00 │   33.5361985472155 │
└─────────────────────┴────────────────────┘

Ok. 23 rows in set. Elapsed: 6.891 sec. Processed: 0 rows, 0.0B (0 rows/s, 0.0B/s)

对于这么简单的操作，7s 似乎很慢。

我们这样做的方式是错误的吗？

标签： databasetime-seriesclickhouse

解决方案

您不使用分区和主索引。

  1. 您有 3 列具有相同的时态数据。当您查询ts并且time您的查询处理更多数据时。摆脱time和date列！！！！！！！！！！！！！！！

  2. 您的表按列分区date，您的where部分使用AND ts > 1629378660000=== 分区消除不起作用！！！使用partition by toYYYYMM(toDateTime(intDiv(ts,1000))！

  3. 不使用round(ts/1000)，使用intDiv(ts,1000)

  4. 您不使用主键索引。查询优化器是愚蠢的，使用+ GROUP BY uuid, agreg ORDER BY uuid, agreg ASC try从set optimize_aggregation_in_order=1.agregts

(uuid, agreg (ts) )对匹配表的ORDER BY

  1. 是的，CH 仍然会比其他时间序列数据库慢，因为 CH 不是为此类查询而设计的。

推荐阅读