我有一个名为transactions(简称别名txs)的表，其中包含 1500 万行PARTITIONED BY txs.year过去 10 年(大约 1 到 150 万行/年)积累的数据。此数据的来源是MySQL数据库，唯一更改的数据是current year的数据。我的策略是设置一个每日 CRON 作业，该作业以压缩的 CSV 格式导出current year的所有记录(即20XX-txs.csv.gz)，然后使用 AWS Glue/PySpark 将其转换为snappy.parquet格式PARTITIONED BY txs.year。
我读过你可以用ClickHouse(参考)轻松DROP PARTITIONS。有一件事让我失望，没有任何进一步的解释。他们的文件指出：
从表中删除指定的分区。此查询标记 分区为非活动状态并完全删除数据，大约在 10分钟。
我想知道的是：
- 10 分钟部分从何而来？从我的测试中，我看到分区立即消失了。
- 是否可以在
DROPPING过时分区后立即从新创建的snappy.parquet分区INSERT更新的数据current_year，还是必须等待整整10 分钟才能执行此操作？
示例用例：
# STEP 1: Get updated data for current_year
# -----------------------------------------
$ wget https://s3.amazonaws.com/xxx.xxx/2021-txs.snappy.parquet
# STEP 2: Drop existing PARTITION for current_year
# -----------------------------------------
$ clickhouse-client --query="ALTER TABLE txs DROP PARTITION '2021'"
# STEP 3: INSERT updated data for current_year into the table
# -----------------------------------------
$ cat 2021-txs.snappy.parquet | clickhouse-client --query="INSERT INTO txs FORMAT Parquet"
这与您的用例无关。
这是关于从磁盘中删除数据，而不是关于表。(用户有时会担心磁盘释放)
此查询将分区标记为非活动 并完全删除数据，大约在 10 分钟内。
这是合并的有趣副作用。
使用删除分区立即删除活动部件，但非活动部件不是。
创建表 t(a Int64) 引擎=合并树顺序为 a; 插入 t 值 (1); 选择名称，从系统部件中激活，其中表 = 't'; ┌─姓名──────┬─活跃─┐ │ all_1_1_0 │ 1 │ └───────────┴────────┘ 优化表T最终; -- 强制合并产生了新部分all_1_1_1(活动)并保留旧部分 -- 第 all_1_1_0 部分(非活动)。 选择名称，从系统部件中激活，其中表 = 't'; ┌─姓名──────┬─活跃─┐ │ all_1_1_0 │ 0 │ │ all_1_1_1 │ 1 │ └───────────┴────────┘ 更改表 T 删除分区元组(); -- 数据被删除 -- 但只有有源部件 从 t 中选择 count(); ┌─计数()─┐ │ 0 │ └─────────┘ -- 但非活动部件仍在等待 -- 后台进程在 8 分钟不活动后丢弃它们 选择名称，从系统部件中激活，其中表 = 't'; ┌─姓名──────┬─活跃─┐ │ all_1_1_0 │ 0 │ └───────────┴────────┘ ls -1/var/lib/clickhouse/data/default/t/all_1_1_0 超然 format_version.txt
10 分钟，实际上是 8 分钟(480 秒)由merge_tree设置old_parts_lifetime控制
谷歌翻译：非活动部分不会立即删除，因为在写入新块时，不会调用fsync，即一段时间内新块仅位于服务器的 RAM(操作系统缓存)中。因此，如果服务器自发重新启动，则刚刚合并的新部件可能会丢失或损坏。然后 ClickHouse 在启动过程中检查部件的完整性，可以检测到问题，将非活动部件返回到活动列表，然后再次合并它们。然后重命名损坏的部分(添加前缀损坏)并移动到分离的文件夹。如果完整性检查在合并的区块中没有检测到问题，则会重命名原始的非活动区块(添加忽略前缀)并移动到分离的文件夹中。