如何在clickhouse的主键中使用`toYYYYMMDD(timestamp)`

Question

我使用 clickhouse 作为我的项目底层数据库及其MergeTree 表引擎。我正在尝试使用Custom Partitioning Key 功能，我创建了这样的表：

CREATE TABLE MyTable
(    
        UserID UUID,     
        ResourceID UUID,        
        TimeStamp DateTime,         
        Usage Int64,
        Version UInt32
)
ENGINE = ReplacingMergeTree(Version)
PARTITION BY toYYYYMM(TimeStamp)
ORDER BY (toYYYYMMDD(TimeStamp), UserID, ResourceID , TimeStamp)

分区键是toYYYYMM(TimeStamp)，这意味着clickhouse按月分隔数据。同时，我使用toYYYYMMDD(TimeStamp) 作为主索引的第一列。我提取了 1 年的数据（每月大约 30-40 百万行）进行测试。

当我使用TimeStamp 过滤条件查询数据时，我得到一些令人困惑的结果。这是我的 sql：

select count(*) from MyTable WHERE 
TimeStamp>=toDateTime('2019-01-30 00:00:00') 
and 
TimeStamp<toDateTime('2019-02-04 00:00:00')

它处理了7562万行（1月和2月的全部数据）！这意味着查询条件可以命中正确的分区但错过了主键。但是如果手动转换TimeStamp，像这样：

select count(*) from MyTable WHERE
toYYYYMMDD(TimeStamp)>=toYYYYMMDD(toDateTime('2019-01-30 00:00:00')) 
and 
toYYYYMMDD(TimeStamp)<toYYYYMMDD(toDateTime('2019-02-04 00:00:00'))

然后它只处理了 700 万行（5-6 天的数据）。这意味着查询条件命中了主键。

让我困惑的是，既然 clickhouse 可以在不转换 TimeStamp 的情况下命中正确的分区，为什么它也不能自动命中主键？我真的需要手动转换时间戳吗？

Answer 1

您的表定义向用于定义行数据索引的 ORDER BY 中添加了太多信息。我猜当您将过滤条件指定为 toDateTime('2019-01-30 00:00:00') 时，ClickHouse 无法使用索引的第一部分。结果，它最终读取了整个部分。尝试按如下方式定义您的表：

CREATE TABLE MyTable (
        UserID UUID,
        ResourceID UUID,
        TimeStamp DateTime,
        Usage Int64,
        Version UInt32 ) 
ENGINE = ReplacingMergeTree(Version)
PARTITION BY toYYYYMM(TimeStamp)
ORDER BY (UserID, ResourceID ,TimeStamp)

在这种情况下，您应该看到两个查询的性能相同。在这两种情况下，它可能比过滤器与索引的第一列完全匹配的最快查询慢一点，但比不匹配的情况快很多。

有关正在发生的事情的更多信息，请查看 ClickHouse 日志，该日志位于 /var/log/clickhouse-server/clickhouse-server.log 中。您会看到消息告诉您 ClickHouse 实际读取了多少数据来进行计数。这是一个例子。

2019.08.29 14:46:39.507239 [ 41 ] {fc8cb747-5db2-40ac-afeb-32b61192de9a} <Debug> executeQuery: (from 127.0.0.1:49598) SELECT count(*) FROM MyTable WHERE (TimeStamp >= toDateTime('2019-09-30 00:00:00')) AND (TimeStamp < toDateTime('2019-10-04 00:00:00')) 
...
2019.08.29 14:46:39.518160 [ 41 ] {fc8cb747-5db2-40ac-afeb-32b61192de9a} <Debug> default.MyTable (SelectExecutor): Selected 2 parts by date, 2 parts by key, 63 marks to read from 11 ranges
2019.08.29 14:46:39.518739 [ 41 ] {fc8cb747-5db2-40ac-afeb-32b61192de9a} <Trace> default.MyTable (SelectExecutor): Reading approx. 516096 rows with 2 streams

在这种情况下，我们可以看到它选择了相对较少的标记（即数据颗粒）来读取。这让您了解主键索引的工作效率。