ClickHouse的Insertt和Mutation(update,delete)操作

1、 insert操作

创建一个表

CREATE TABLE tmp.meta
(
    `meta_type` String ,
    `meta_value` String
)
ENGINE = MergeTree
ORDER BY meta_type

插入数据

insert into meta(meta_type,meta_value) 
values('aaa', 'aaaaa'), ('aaab', 'aaaaab');

查看文件存储结果
进行表的存放目录(/var/lib/clickhouse/data/tmp/meta)

tree命令查看结构

.
├── all_1_1_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── detached
└── format_version.txt

再次插入数据

insert into tmp.meta(meta_type,meta_value) 
values('aaa1', 'aaaaa1');

两次查看结构

.
├── all_1_1_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── all_2_2_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── detached
└── format_version.txt

由此可见多生成了一个分区目录

手动合并分区

OPTIMIZE TABLE tmp.meta;

再次查看目录

.
├── all_1_1_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── all_1_2_1
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── all_2_2_0
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── detached
└── format_version.txt

发现多一个目录 all_1_2_1 ,而且旧的分区目录也还在。(all_1_2_1这个就是合并后的分区目录,旧的目录删除有一定的延迟性),查看系统表system.parts可以看到

select partition_id,name,active
from system.parts partit
where database = 'tmp' and `table` ='meta'
;

两个旧分区的active是为0,表示是失效的意思

┌─partition_id─┬─name──────┬─active─┐
│ all          │ all_1_1_0 │      0 │
│ all          │ all_2_2_0 │      0 │
│ all          │ all_1_2_1 │      1 │
└──────────────┴───────────┴────────┘

等几分钟后会再次查询会发现只剩下 all_2_2_0 分区了

┌─partition_id─┬─name──────┬─active─┐
│ all          │ all_1_2_1 │      1 │
└──────────────┴───────────┴────────┘

2、 Mutation(update,delete)操作

先看update语法

alter table meta update meta_value='ababababa' where meta_type='aaa';

查看目录结构

.
├── all_1_2_1
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── all_1_2_1_3
│   ├── checksums.txt
│   ├── columns.txt
│   ├── count.txt
│   ├── data.bin
│   ├── data.mrk3
│   ├── default_compression_codec.txt
│   └── primary.idx
├── detached
├── format_version.txt
└── mutation_3.txt

多了一个合并后的目录 all_1_2_1_3,还多了一个 mutation_3.txt 文件
打开mutation_3.txt

format version: 1
create time: 2022-07-27 14:37:34
commands: UPDATE meta_value = \'ababababa\' WHERE meta_type = \'aaa\'

可以看到这个就是刚刚执行修改的语句

查看ClickHouse的系统表中有一个system.mutations(mutation翻译过来中文是“突变”,在这里可能引申为订正更合适。)

select * from system.mutations
where database='tmp' and table='meta' \G
SELECT *
FROM system.mutations
WHERE (database = 'tmp') AND (table = 'meta')

Query id: d97307cd-a9e5-45b7-a878-d504d4a33e9f

Row 1:
──────
database:                   tmp
table:                      meta
mutation_id:                mutation_3.txt
command:                    UPDATE meta_value = 'ababababa' WHERE meta_type = 'aaa'
create_time:                2022-07-27 14:37:34
block_numbers.partition_id: ['']
block_numbers.number:       [3]
parts_to_do_names:          []
parts_to_do:                0
is_done:                    1   (表示是否执行完成)
latest_failed_part:         
latest_fail_time:           1970-01-01 08:00:00
latest_fail_reason:         

这里也可以看到刚刚的语句,但是insert语句这里没有。

如果某个命令长时间不执行,可以通过以下终止执行。

KILL MUTATION WHERE database = 'bdp' AND table = 'meta_dmp'

执行这个命令后对应的mutation_*.txt 文件也会被删除

不过有一次,我们库里面执行了一个修改操作,导致表都无法访问,KILL MUTATION 操作也无法执行。甚至是SELECT count() FROM system.mutations也卡死。重启clickhouse服务都无法回退。最后是删除表存储目录下面的 mutation_*.txt 然后再重启解决。

之前看有些文章说 mutation_*.txt是执行 mutation的日志,由些看不完全是。也不知道是不是他本身的Bug。
我们使用的版本是:

ClickHouse client version 21.4.4.30 (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.4.4 revision 54447.

删除操作

alter table meta delete where meta_type='aaa1';

执行删除操作也是会合并到另一个分区


SELECT
    partition_id,
    name,
    active
FROM system.parts AS partit
WHERE (database = 'tmp') AND (table = 'meta')

Query id: 421e01c4-879c-4b26-b8e0-bbc38d1015de

┌─partition_id─┬─name────────┬─active─┐
│ all          │ all_1_2_1_3 │      0 │
│ all          │ all_1_2_1_4 │      1 │
└──────────────┴─────────────┴────────┘

system.mutations也会产生一记录

Row 2:
──────
database:                   tmp
table:                      meta
mutation_id:                mutation_4.txt
command:                    DELETE WHERE meta_type = 'aaa1'
create_time:                2022-07-27 15:05:09
block_numbers.partition_id: ['']
block_numbers.number:       [4]
parts_to_do_names:          []
parts_to_do:                0
is_done:                    1
latest_failed_part:         
latest_fail_time:           1970-01-01 08:00:00
latest_fail_reason:         

3、总结

ClickHouse的insert,update和delete操作合并到新的分区。所以也就是为啥叫合并树引擎的原因吧。

为了减少系统的合并工作,要尽量减少小批量频繁的操作,尽量不要使用update和delete操作,特别是大表。有可能导致表无法访问的情况。

你可能感兴趣的:(ClickHouse的Insertt和Mutation(update,delete)操作)