From 59aa618312ec77bd4ab3ee23479f694ccf9e769c Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Wed, 3 Sep 2025 13:05:31 +0000 Subject: [PATCH 1/2] [INIT] Start translation to Simplified-Chinese --- .translation-init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.translation-init b/.translation-init index 48c98cd5d8..fe283689cc 100644 --- a/.translation-init +++ b/.translation-init @@ -1 +1 @@ -Translation initialization: 2025-09-03T09:07:20.601831 +Translation initialization: 2025-09-03T13:05:30.749701 From 807e325f8329296a8b05e05f4d7397f993702db8 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Wed, 3 Sep 2025 13:08:47 +0000 Subject: [PATCH 2/2] =?UTF-8?q?=F0=9F=8C=90=20Translate=2060-optimize-tabl?= =?UTF-8?q?e.md=20to=20Simplified-Chinese?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../00-ddl/01-table/60-optimize-table.md | 172 +++++------------- 1 file changed, 44 insertions(+), 128 deletions(-) diff --git a/docs/cn/sql-reference/10-sql-commands/00-ddl/01-table/60-optimize-table.md b/docs/cn/sql-reference/10-sql-commands/00-ddl/01-table/60-optimize-table.md index 2e8b665b1c..867f13c576 100644 --- a/docs/cn/sql-reference/10-sql-commands/00-ddl/01-table/60-optimize-table.md +++ b/docs/cn/sql-reference/10-sql-commands/00-ddl/01-table/60-optimize-table.md @@ -8,66 +8,65 @@ import FunctionDescription from '@site/src/components/FunctionDescription'; import DetailsWrap from '@site/src/components/DetailsWrap'; -在 Databend 中优化表包括压缩或清除历史数据，以节省存储空间并提高查询性能。 +在 Databend 中优化表，即通过合并或清理历史数据来节省存储空间并提升查询性能。
- 为什么要优化？ -
Databend 使用 Parquet 格式将数据存储在表中，Parquet 格式被组织成块。此外，Databend 支持时间回溯功能，其中每个修改表的操作都会生成一个 Parquet 文件，该文件捕获并反映对表所做的更改。

+ 为何需要优化？ +
Databend 使用 Parquet 格式将数据存储在表中，并按块（Block）组织。此外，Databend 支持时间回溯（Time Travel）功能，每次修改表的操作都会生成一个 Parquet 文件，用于捕获并反映对表的变更。

-
随着时间的推移，当一个表积累了更多的 Parquet 文件时，可能会导致性能问题和存储需求的增加。为了优化表的性能，可以删除不再需要的历史 Parquet 文件。这种优化有助于提高查询性能并减少表使用的存储空间量。
+
随着时间推移，表会累积大量 Parquet 文件，可能导致性能下降和存储需求增加。为优化表性能，可在不再需要时删除历史 Parquet 文件。这种优化有助于提升查询性能并减少表占用的存储空间。
 -## Databend 数据存储：快照、段和块 +## Databend 数据存储：快照、段与块 -快照、段和块是 Databend 用于数据存储的概念。Databend 使用它们来构建用于存储表数据的分层结构。 +快照（Snapshot）、段（Segment）和块（Block）是 Databend 用于数据存储的核心概念，Databend 利用它们构建表数据的分层存储结构。 ![](/img/sql/storage-structure.PNG) -Databend 在数据更新时自动创建表快照。快照表示表段元数据的版本。 +Databend 在数据更新时会自动创建表快照。快照代表表某一版本的段元数据。 -当使用 Databend 时，当您使用 [AT](../../20-query-syntax/03-query-at.md) 子句检索和查询表的先前版本的数据时，您最有可能使用快照 ID 访问快照。 +使用 Databend 时，若通过 [AT](../../20-query-syntax/03-query-at.md) 子句检索并查询表的历史版本数据，通常需借助快照 ID 访问快照。 -快照是一个 JSON 文件，它不保存表的数据，但指示快照链接到的段。如果您对表运行 [FUSE_SNAPSHOT](../../../20-sql-functions/16-system-functions/fuse_snapshot.md)，您可以找到为该表保存的快照。 +快照是一个 JSON 文件，不存储表数据，但记录了快照关联的段。对表执行 [FUSE_SNAPSHOT](../../../20-sql-functions/16-system-functions/fuse_snapshot.md) 可查看保存的快照。 -段是一个 JSON 文件，用于组织存储数据的存储块（至少 1 个，最多 1,000 个）。如果您使用快照 ID 对快照运行 [FUSE_SEGMENT](../../../20-sql-functions/16-system-functions/fuse_segment.md)，您可以找到快照引用的段。 +段是一个 JSON 文件，用于组织存储数据的块（至少 1 个，最多 1,000 个）。使用快照 ID 对快照执行 [FUSE_SEGMENT](../../../20-sql-functions/16-system-functions/fuse_segment.md) 可查看该快照引用的段。 -Databends 将实际表数据保存在 parquet 文件中，并将每个 parquet 文件视为一个块。如果您使用快照 ID 对快照运行 [FUSE_BLOCK](../../../20-sql-functions/16-system-functions/fuse_block.md)，您可以找到快照引用的块。 +Databend 将实际表数据存储在 Parquet 文件中，并将每个 Parquet 文件视为一个块。使用快照 ID 对快照执行 [FUSE_BLOCK](../../../20-sql-functions/16-system-functions/fuse_block.md) 可查看该快照引用的块。 -Databend 为每个数据库和表创建一个唯一的 ID，用于存储快照、段和块文件，并将它们保存到对象存储中的路径 `////`。每个快照、段和块文件都使用 UUID（32 个字符的小写十六进制字符串）命名。 +Databend 为每个数据库和表创建唯一 ID，用于存储快照、段和块文件，并将其保存至对象存储路径 `////`。每个快照、段和块文件均以 UUID（32 位小写十六进制字符串）命名。 -| 文件 | 格式 | 文件名 | 存储文件夹 | +| 文件 | 格式 | 文件名 | 存储文件夹 | |----------|---------|---------------------------------|-----------------------------------------------------| -| Snapshot | JSON | `<32bitUUID>_.json` | `////_ss/` | -| Segment | JSON | `<32bitUUID>_.json` | `////_sg/` | -| Block | parquet | `<32bitUUID>_.parquet` | `////_b/` | +| 快照 | JSON | `<32bitUUID>_.json` | `////_ss/` | +| 段 | JSON | `<32bitUUID>_.json` | `////_sg/` | +| 块 | parquet | `<32bitUUID>_.parquet` | `////_b/` | ## 表优化 -在 Databend 中，建议以 100MB（未压缩）或 1,000,000 行作为理想的块大小，每个段由 1,000 个块组成。为了最大限度地优化表，至关重要的是要清楚地了解何时以及如何应用各种优化技术，例如 [段压缩](#segment-compaction)、[块压缩](#block-compaction) 和 [清除](#purging)。 +在 Databend 中，建议的理想块大小为 100 MB（未压缩）或 1,000,000 行，每个段包含 1,000 个块。为最大化表优化效果，需明确何时以及如何应用各种优化技术，如[段合并](#segment-compaction)和[块合并](#block-compaction)。 +- 使用 COPY INTO 或 REPLACE INTO 命令向包含聚簇键（Cluster Key）的表写入数据时，Databend 会自动触发重聚簇以及段和块合并流程。 -- 当使用 COPY INTO 或 REPLACE INTO 命令将数据写入包含聚簇键的表时，Databend 将自动启动重新聚簇过程，以及段和块压缩过程。 - -- 段和块压缩支持在集群环境中进行分布式执行。您可以通过将 ENABLE_DISTRIBUTED_COMPACT 设置为 1 来启用它们。这有助于提高集群环境中的数据查询性能和可伸缩性。 +- 段与块合并支持在集群环境中分布式执行。可通过设置 ENABLE_DISTRIBUTED_COMPACT 为 1 启用，以提升集群环境中的查询性能和可扩展性。 ```sql SET enable_distributed_compact = 1; ``` -### 段压缩 +### 段合并（Segment Compaction） -当一个表有太多小段（每个段小于 `100 blocks`）时，压缩段。 +当表存在过多小段（每段少于 `100 个块`）时，需进行段合并。 ```sql SELECT block_count, segment_count, IF( block_count / segment_count < 100, - 'The table needs segment compact now', - 'The table does not need segment compact now' + '该表当前需进行段合并', + '该表当前无需段合并' ) AS advice FROM fuse_snapshot('your-database', 'your-table') @@ -80,21 +79,21 @@ FROM OPTIMIZE TABLE [database.]table_name COMPACT SEGMENT [LIMIT ] ``` -通过将小段合并为大段来压缩表数据。 +通过合并小段为较大段来优化表数据。 -- 选项 LIMIT 设置要压缩的最大段数。在这种情况下，Databend 将选择并压缩最新的段。 +- LIMIT 选项设置最大合并段数，Databend 将选择并合并最新段。 **示例** ```sql --- Check whether need segment compact +-- 检查是否需段合并 SELECT block_count, segment_count, IF( block_count / segment_count < 100, - 'The table needs segment compact now', - 'The table does not need segment compact now' + '该表当前需进行段合并', + '该表当前无需段合并' ) AS advice FROM fuse_snapshot('hits', 'hits'); @@ -105,17 +104,17 @@ FROM | 751 | 32 | The table needs segment compact now | +-------------+---------------+-------------------------------------+ --- Compact segment +-- 执行段合并 OPTIMIZE TABLE hits COMPACT SEGMENT; --- Check again +-- 再次检查 SELECT block_count, segment_count, IF( block_count / segment_count < 100, - 'The table needs segment compact now', - 'The table does not need segment compact now' + '该表当前需进行段合并', + '该表当前无需段合并' ) AS advice FROM fuse_snapshot('hits', 'hits') @@ -128,13 +127,13 @@ FROM +-------------+---------------+---------------------------------------------+ ``` -### 块压缩 +### 块合并（Block Compaction） -当一个表有大量小块或当该表有很高比例的插入、删除或更新的行时，压缩块。 +当表存在大量小块，或插入、删除、更新行比例较高时，需进行块合并。 -您可以通过检查每个块的未压缩大小是否接近 `100MB` 的完美大小来检查它。 +可通过检查每个块的未压缩大小是否接近理想值 `100 MB` 来判断。 -如果大小小于 `50MB`，我们建议进行块压缩，因为它表示有太多小块： +若大小小于 `50 MB`，建议执行块合并，表明存在过多小块： ```sql SELECT @@ -142,8 +141,8 @@ SELECT humanize_size(bytes_uncompressed / block_count) AS per_block_uncompressed_size, IF( bytes_uncompressed / block_count / 1024 / 1024 < 50, - 'The table needs block compact now', - 'The table does not need block compact now' + '该表当前需进行块合并', + '该表当前无需块合并' ) AS advice FROM fuse_snapshot('your-database', 'your-table') @@ -151,107 +150,24 @@ FROM ``` :::info -我们建议先执行段压缩，然后再执行块压缩。 +建议先执行段合并，再执行块合并。 ::: **语法** ```sql OPTIMIZE TABLE [database.]table_name COMPACT [LIMIT ] ``` -通过将小块和段合并为大块和段来压缩表数据。 +通过合并小块和段为较大块和段来优化表数据。 -- 此命令创建最新表数据的新快照（以及压缩的段和块），而不影响现有存储文件，因此在您清除历史数据之前，不会释放存储空间。 +- 该命令会为最新表数据创建新快照（含合并后的段和块），不影响现有存储文件，故需清理历史数据后才会释放存储空间。 -- 根据给定表的大小，完成执行可能需要相当长的时间。 +- 根据表大小，执行可能耗时较长。 -- 选项 LIMIT 设置要压缩的最大段数。在这种情况下，Databend 将选择并压缩最新的段。 +- LIMIT 选项设置最大合并段数，Databend 将选择并合并最新段。 -- Databend 将在压缩过程后自动重新聚簇聚簇表。 +- 合并完成后，Databend 会自动对聚簇表执行重聚簇。 **示例** ```sql OPTIMIZE TABLE my_database.my_table COMPACT LIMIT 50; -``` - -### 清除 - -清除会永久删除历史数据，包括未使用的快照、段和块，但保留期内的快照（包括此快照引用的段和块）除外。这可以节省存储空间，但可能会影响时间回溯功能。在以下情况下考虑清除： - -- 存储成本是一个主要问题，并且您不需要历史数据用于时间回溯或其他目的。 -- 您已经压缩了您的表，并且想要删除较旧的、未使用的的数据。 - -:::note -默认保留期为 24 小时的历史数据将不会被删除。要调整保留期，请使用 *data_retention_time_in_days* 设置。 -::: - -**语法** - -```sql -OPTIMIZE TABLE PURGE - [ BEFORE - (SNAPSHOT => '') | - (TIMESTAMP => ''::TIMESTAMP) | - (STREAM => ) - ] - [ LIMIT ] -``` - -| 参数 | 描述 | -|-----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| BEFORE | 指定清除历史数据的条件。它与 `SNAPSHOT`、`TIMESTAMP` 或 `STREAM` 选项一起使用，以定义应清除数据的时间点。
当指定 `BEFORE` 选项时，该命令首先选择一个基本快照（如指定选项所示）来清除历史数据。随后，它会删除在此基本快照之前生成的快照。在指定带有 `BEFORE STREAM` 的流的情况下，该命令会将创建流之前的最近快照识别为基本快照。然后，它会删除在此最近快照之前生成的快照。| -| LIMIT | 设置要清除的最大快照数。指定后，Databend 将选择并清除最旧的快照，最多达到指定的计数。 | - -**示例** - -此示例演示如何使用 `BEFORE STREAM` 选项清除历史数据。 - -1. 创建一个名为 `t` 的表，其中包含一个列 `a`，并将两行值 1 和 2 插入到表中。 - -```sql -CREATE TABLE t(a INT); - -INSERT INTO t VALUES(1); -INSERT INTO t VALUES(2); -``` - -2. 在表 `t` 上创建一个名为 `s` 的流，并将一个值为 3 的附加行添加到表中。 - -```sql -CREATE STREAM s ON TABLE t; - -INSERT INTO t VALUES(3); -``` - -3. 返回表 `t` 的快照 ID 和相应的时间戳。 - -```sql -SELECT snapshot_id, timestamp FROM FUSE_SNAPSHOT('default', 't'); - -┌───────────────────────────────────────────────────────────────┐ -│ snapshot_id │ timestamp │ -├──────────────────────────────────┼────────────────────────────┤ -│ 00dd8ca67c1f461987f31a6b3a1c3c84 │ 2024-04-02 18:09:39.157702 │ -│ e448bb2bf488489dae7294b0a8af38d1 │ 2024-04-02 18:09:34.986507 │ -│ 2ac038dd83e741afbae543b170105d63 │ 2024-04-02 18:09:34.966336 │ -└───────────────────────────────────────────────────────────────┘ - --- 仅出于演示目的，将数据保留时间设置为 0。不建议在生产中使用。 -SET data_retention_time_in_days = 0; -``` - -4. 使用 `BEFORE STREAM` 选项清除历史快照。 - -```sql -OPTIMIZE TABLE t PURGE BEFORE (STREAM => s); - --- 该命令选择快照 ID e448bb2bf488489dae7294b0a8af38d1 作为基本快照，该快照是在创建流“s”之前立即生成的。 --- 因此，将删除在基本快照之前生成的快照 ID 2ac038dd83e741afbae543b170105d63。 -SELECT snapshot_id, timestamp FROM FUSE_SNAPSHOT('default', 't'); - -┌───────────────────────────────────────────────────────────────┐ -│ snapshot_id │ timestamp │ -├──────────────────────────────────┼────────────────────────────┤ -│ 00dd8ca67c1f461987f31a6b3a1c3c84 │ 2024-04-02 18:09:39.157702 │ -│ e448bb2bf488489dae7294b0a8af38d1 │ 2024-04-02 18:09:34.986507 │ -└───────────────────────────────────────────────────────────────┘ ``` \ No newline at end of file