问题描述
如何确保提交给 CH 的突变实际运行?
我有一个事实表,我们称之为表 A。它包含 8'904'390 条记录。
我还有一个元数据表,表 B。它包含 14'790'739 条记录。
我有兴趣加入他们以制作更快的桌子。 因此,我创建了一个新表 A + B。它从 A 中选择了列,从 B 中选择了列。
当我用历史数据填充新表时,内存不足。
执行与此类似的简单 INSERT INTO
语句:
INSERT INTO A+B SELECT
id,time,price,buyer.gender as buyer_gender
FROM
(
SELECT
id,buyer_ref,price
FROM A
)
LEFT JOIN
(
SELECT
ref,gender
FROM B
) AS buyer ON buyer_ref = ref
因此,我找到了这个聪明的解决方案,而不是手动对要插入的数据进行分区:
Updating rows with values from another table in ClickHouse
这个想法是首先用来自 A 的数据填充 A+B 表, 然后用来自 B 的数据更新它。
我试过跑步
ALTER TABLE A+B UPDATE buyer_gender=joinGet('buyer_join','gender',buyer_ref) where buyer_gender=''
执行了查询并将一条记录添加到 system.mutations
表中。
我回家 24 小时后回来,结果还没有完成,is_done 仍然是 0,而且 A+B 表的 buyer_gender
列中没有来自 B 的任何数据。
clickhouse.logs 非常安静:
2021.02.12 11:16:03.631674 [ 153 ] {0e304bff-8563-4219-baf9-27294a84feac} <Debug> executeQuery: (from 172.22.0.1:52862) ALTER TABLE A+B UPDATE buyer_gender=joinGet('buyer_join',buyer_id) where gender=''
2021.02.12 11:16:03.641182 [ 153 ] {0e304bff-8563-4219-baf9-27294a84feac} <information> db_name.A+B: Added mutation: mutation_216.txt
2021.02.12 11:16:03.641210 [ 153 ] {0e304bff-8563-4219-baf9-27294a84feac} <information> db_name.A+B: Waiting mutation: mutation_216.txt
2021.02.12 11:17:35.873119 [ 154 ] {14b270a0-281a-4d0a-b3be-4ce5059d853d} <Debug> executeQuery: (from 172.22.0.1:36140) select * from system.mutations
2021.02.12 11:17:35.873626 [ 154 ] {14b270a0-281a-4d0a-b3be-4ce5059d853d} <Trace> ContextAccess (default): Access granted: SELECT(database,table,mutation_id,command,create_time,`block_numbers.partition_id`,`block_numbers.number`,parts_to_do_names,parts_to_do,is_done,latest_Failed_part,latest_fail_time,latest_fail_reason) ON system.mutations
2021.02.12 11:17:39.557393 [ 154 ] {fdabc8d1-488c-4b47-a35e-afd80f288fa6} <Debug> executeQuery: (from 172.22.0.1:36140) select * from system.mutations Format Vertical
2021.02.12 11:17:39.557868 [ 154 ] {fdabc8d1-488c-4b47-a35e-afd80f288fa6} <Trace> ContextAccess (default): Access granted: SELECT(database,latest_fail_reason) ON system.mutations
并且 clickhouse.error.logs 不包含与此突变相关的任何内容。
我尝试仅使用上面的 joinGet
从连接表中的一列中选择表 A 的查询。大约需要10s。
我尝试了一个 ALTER TABLE UPDATE
语句,我将 buyer_gender
列值分配给一个常量字符串 'foo'。
它的执行速度也非常快。这两个操作似乎都没有使用大量内存。但是将 joinGet
与 ALTER TABLE UPDATE
结合似乎永远不会结束,我什至不知道它是否已经开始。
所以我的问题是如何触发突变? 如果不可能,那么对于这个操作和数据量来说,超过 24 小时是否正常?
ClickHouse 服务器版本 20.6.5 修订版 54436
解决方法
我最终退后一步,直接使用连接表引擎插入 A + B 表。这样我们就不需要运行导致“缓慢”突变的更新语句。
出于某种原因,当使用连接表引擎而不是旧的 LEFT OUTER JOIN
时,CH 可以更好地管理其内存。
没有回答为什么 Mutation 会挂起。