我可以在删除旧分区后立即导入更新分区吗?
Can I import an UPDATED PARTITION right after I DROP the old one?
我有一个名为 transactions
(简称 txs
)的 table,其中包含 1500 万行 PARTITIONED BY txs.year
过去 10 年(大约1 到 150 万 rows/year)。此数据的来源是 MySQL 数据库,唯一更改的数据是 current year
的数据。我的策略是设置每日 CRON 作业,以压缩的 CSV 格式(即 20XX-txs.csv.gz
)导出 current year
的所有记录,然后使用 AWS Glue/PySpark 将其转换为 snappy.parquet
格式 PARTITIONED BY txs.year
.
我了解到您可以轻松 DROP PARTITIONS
使用 ClickHouse (reference)。没有任何进一步的解释,有一件事让我失望。他们的文档说明:
Deletes the specified partition from the table. This query tags the
partition as inactive and deletes data completely, approximately in
10 minutes.
我想知道的是:
- 10 分钟 部分从何而来?从我的测试中,我看到分区立即消失了。
- 我可以
INSERT
在 DROPPING
current_year
的陈旧分区之后立即从新创建的 snappy.parquet
分区更新数据吗?还是必须等待完整的 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"
它与您的用例无关。
它是关于从磁盘中删除数据,而不是 table。 (用户有时会担心磁盘释放)
This query tags the partition as inactive
and deletes data completely, approximately in 10 minutes.
这是合并的有趣副作用。
使用 DROP PARTITION 立即删除活动部分但不活动的部分则不会。
create table t(a Int64) Engine=MergeTree order by a;
insert into t values (1);
select name, active from system.parts where table = 't';
┌─name──────┬─active─┐
│ all_1_1_0 │ 1 │
└───────────┴────────┘
optimize table t final;
-- forced merge produced the new part all_1_1_1 (active) and left the old
-- part all_1_1_0 (inactive).
select name, active from system.parts where table = 't';
┌─name──────┬─active─┐
│ all_1_1_0 │ 0 │
│ all_1_1_1 │ 1 │
└───────────┴────────┘
alter table t drop partition tuple(); -- DATA IS DROPPED
-- but only active parts
select count() from t;
┌─count()─┐
│ 0 │
└─────────┘
-- but inactive parts are still in waiting for
-- background process to drop them after 8 minutes inactivity
select name, active from system.parts where table = 't';
┌─name──────┬─active─┐
│ all_1_1_0 │ 0 │
└───────────┴────────┘
ls -1 /var/lib/clickhouse/data/default/t/
all_1_1_0
detached
format_version.txt
10 - 分钟,实际上 8(480 秒)由 merge_tree 设置 old_parts_lifetime
控制
google 翻译:不活跃的部分不会立即删除,因为在写入新块时,不会调用fsync
,即一段时间内新块仅位于在服务器的 RAM 中(OS 缓存)。因此,如果服务器自发地重新启动,刚刚合并的新部分可能会丢失或损坏。然后ClickHouse在启动过程中正在检查部件的完整性,可以检测到一个问题,return将非活动部件添加到活动列表中,稍后再次合并它们。然后将损坏的部分重命名(添加前缀 broken)并移动到分离的文件夹中。如果完整性检查未检测到合并块中的问题,则原始非活动块将被重命名(添加忽略前缀)并移动到分离文件夹。
我有一个名为 transactions
(简称 txs
)的 table,其中包含 1500 万行 PARTITIONED BY txs.year
过去 10 年(大约1 到 150 万 rows/year)。此数据的来源是 MySQL 数据库,唯一更改的数据是 current year
的数据。我的策略是设置每日 CRON 作业,以压缩的 CSV 格式(即 20XX-txs.csv.gz
)导出 current year
的所有记录,然后使用 AWS Glue/PySpark 将其转换为 snappy.parquet
格式 PARTITIONED BY txs.year
.
我了解到您可以轻松 DROP PARTITIONS
使用 ClickHouse (reference)。没有任何进一步的解释,有一件事让我失望。他们的文档说明:
Deletes the specified partition from the table. This query tags the partition as inactive and deletes data completely, approximately in 10 minutes.
我想知道的是:
- 10 分钟 部分从何而来?从我的测试中,我看到分区立即消失了。
- 我可以
INSERT
在DROPPING
current_year
的陈旧分区之后立即从新创建的snappy.parquet
分区更新数据吗?还是必须等待完整的 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"
它与您的用例无关。
它是关于从磁盘中删除数据,而不是 table。 (用户有时会担心磁盘释放)
This query tags the partition as inactive and deletes data completely, approximately in 10 minutes.
这是合并的有趣副作用。
使用 DROP PARTITION 立即删除活动部分但不活动的部分则不会。
create table t(a Int64) Engine=MergeTree order by a; insert into t values (1); select name, active from system.parts where table = 't'; ┌─name──────┬─active─┐ │ all_1_1_0 │ 1 │ └───────────┴────────┘ optimize table t final; -- forced merge produced the new part all_1_1_1 (active) and left the old -- part all_1_1_0 (inactive). select name, active from system.parts where table = 't'; ┌─name──────┬─active─┐ │ all_1_1_0 │ 0 │ │ all_1_1_1 │ 1 │ └───────────┴────────┘ alter table t drop partition tuple(); -- DATA IS DROPPED -- but only active parts select count() from t; ┌─count()─┐ │ 0 │ └─────────┘ -- but inactive parts are still in waiting for -- background process to drop them after 8 minutes inactivity select name, active from system.parts where table = 't'; ┌─name──────┬─active─┐ │ all_1_1_0 │ 0 │ └───────────┴────────┘ ls -1 /var/lib/clickhouse/data/default/t/ all_1_1_0 detached format_version.txt
10 - 分钟,实际上 8(480 秒)由 merge_tree 设置 old_parts_lifetime
控制google 翻译:不活跃的部分不会立即删除,因为在写入新块时,不会调用fsync
,即一段时间内新块仅位于在服务器的 RAM 中(OS 缓存)。因此,如果服务器自发地重新启动,刚刚合并的新部分可能会丢失或损坏。然后ClickHouse在启动过程中正在检查部件的完整性,可以检测到一个问题,return将非活动部件添加到活动列表中,稍后再次合并它们。然后将损坏的部分重命名(添加前缀 broken)并移动到分离的文件夹中。如果完整性检查未检测到合并块中的问题,则原始非活动块将被重命名(添加忽略前缀)并移动到分离文件夹。