diff --git a/es/concepts/features/operations/update/replacing-merge-tree.mdx b/es/concepts/features/operations/update/replacing-merge-tree.mdx index 9684fa8de..1e2ad81e9 100644 --- a/es/concepts/features/operations/update/replacing-merge-tree.mdx +++ b/es/concepts/features/operations/update/replacing-merge-tree.mdx @@ -156,7 +156,7 @@ INSERT INTO posts_updateable SELECT ParentId, CommunityOwnedDate, ClosedDate -FROM posts_updateable --seleccionar 100 filas aleatorias +FROM posts_updateable --select 100 random rows WHERE (Id % toInt32(floor(randUniform(1, 11)))) = 0 LIMIT 5000 @@ -191,14 +191,14 @@ INSERT INTO posts_updateable SELECT ParentId, CommunityOwnedDate, ClosedDate -FROM posts_updateable --seleccionar 100 filas aleatorias +FROM posts_updateable --select 100 random rows WHERE (Id % toInt32(floor(randUniform(1, 11)))) = 0 AND AnswerCount > 0 LIMIT 1000 0 rows in set. Elapsed: 0.166 sec. Processed 135.53 thousand rows, 212.65 MB (816.30 thousand rows/s., 1.28 GB/s.) ``` -El resultado de las operaciones anteriores será de 16.000 filas, es decir, 10.000 + 5000 + 1000. Sin embargo, el total correcto aquí es que, en realidad, deberíamos tener solo 1000 filas menos que nuestro total original, es decir, 10.000 - 1000 = 9000. +El resultado de las operaciones anteriores será de 16.000 filas, es decir, 10.000 + 5000 + 1000. En realidad, deberíamos tener solo 1000 filas menos que nuestro total original, es decir, 10.000 - 1000 = 9000. ```sql SELECT count() @@ -210,7 +210,7 @@ FROM posts_updateable 1 row in set. Elapsed: 0.002 sec. ``` -Aquí, los resultados variarán en función de las fusiones que se hayan realizado. Podemos ver que el total es distinto porque tenemos filas duplicadas. Aplicar `FINAL` a la tabla devuelve el resultado correcto. +Los resultados variarán en función de las fusiones que se hayan realizado. Podemos ver que el total difiere debido a las filas duplicadas. Aplicar `FINAL` a la tabla devuelve el resultado correcto. ```sql SELECT count() @@ -359,11 +359,11 @@ Como se explica en Aprovechamiento de particiones con ReplacingMergeTree, recome ### Ajuste de las fusiones para mejorar el rendimiento de las consultas -De forma predeterminada, min_age_to_force_merge_seconds y min_age_to_force_merge_on_partition_only se establecen en 0 y false, respectivamente, lo que desactiva estas funciones. Con esta configuración, ClickHouse aplicará el comportamiento de fusión estándar sin forzar fusiones en función de la antigüedad de la partición. +De forma predeterminada, `min_age_to_force_merge_seconds` y `min_age_to_force_merge_on_partition_only` se establecen en 0 y false, respectivamente, lo que desactiva estas funciones. Con esta configuración, ClickHouse aplicará el comportamiento de fusión estándar sin forzar fusiones en función de la antigüedad de la partición. -Si se especifica un valor para min_age_to_force_merge_seconds, ClickHouse ignorará las heurísticas de fusión habituales para las partes con una antigüedad superior al período especificado. Aunque, en general, esto solo resulta eficaz si el objetivo es minimizar el número total de partes, puede mejorar el rendimiento de las consultas en ReplacingMergeTree al reducir la cantidad de partes que deben fusionarse en tiempo de consulta. +Si se especifica un valor para `min_age_to_force_merge_seconds`, ClickHouse ignorará las heurísticas de fusión habituales para las partes con una antigüedad superior al período especificado. Aunque, en general, esto solo resulta eficaz si el objetivo es minimizar el número total de partes, puede mejorar el rendimiento de las consultas en ReplacingMergeTree al reducir la cantidad de partes que deben fusionarse en tiempo de consulta. -Este comportamiento puede ajustarse aún más estableciendo min_age_to_force_merge_on_partition_only=true, lo que exige que todas las partes de la partición sean más antiguas que min_age_to_force_merge_seconds para aplicar una fusión agresiva. Esta configuración permite que, con el tiempo, las particiones más antiguas se fusionen hasta quedar en una sola parte, lo que consolida los datos y mantiene el rendimiento de las consultas. +Este comportamiento puede ajustarse aún más estableciendo `min_age_to_force_merge_on_partition_only=true`, lo que exige que todas las partes de la partición sean más antiguas que `min_age_to_force_merge_seconds` para aplicar una fusión agresiva. Esta configuración permite que, con el tiempo, las particiones más antiguas se fusionen hasta quedar en una sola parte, lo que consolida los datos y mantiene el rendimiento de las consultas. -ClickHouse の ReplacingMergeTree エンジンは、データパーツをマージして重複する行を管理し、指定した一意キーに基づいて各行の最新バージョンのみを保持するよう最適化されています。ただし、マージ後のパーツが `max_bytes_to_merge_at_max_space_in_pool` のしきい値に達すると、`min_age_to_force_merge_seconds` が設定されていても、以降のマージ対象には選ばれなくなります。その結果、継続的なデータ挿入に伴って蓄積する可能性がある重複の除去を、自動マージに頼ることはできなくなります。 +ClickHouse の ReplacingMergeTree エンジンは、パーツをマージして重複する行を管理し、指定した一意キーに基づいて各行の最新バージョンのみを保持するよう最適化されています。ただし、マージ後のパーツが `max_bytes_to_merge_at_max_space_in_pool` のしきい値に達すると、`min_age_to_force_merge_seconds` が設定されていても、以降のマージ対象には選ばれなくなります。その結果、継続的なデータ挿入に伴って蓄積する可能性がある重複の除去を、自動マージに頼ることはできなくなります。 これに対処するには、`OPTIMIZE FINAL` を実行して、パーツを手動でマージし、重複を削除できます。自動マージとは異なり、`OPTIMIZE FINAL` は `max_bytes_to_merge_at_max_space_in_pool` のしきい値を回避し、利用可能なリソース、特にディスク容量のみに基づいてパーツをマージし、各パーティションでパーツが 1 つだけ残るまで処理を進めます。ただし、この方法は大規模なテーブルではメモリ消費が大きくなる可能性があり、新しいデータが追加されるたびに繰り返し実行が必要になる場合があります。 -パフォーマンスを維持しつつ、より持続可能な解決策とするには、テーブルのパーティション化を推奨します。これにより、データパーツがマージの最大サイズに達するのを防ぎやすくなり、継続的な手動最適化の必要性も減らせます。 +パフォーマンスを維持しつつ、より持続可能な解決策とするには、テーブルのパーティション化を推奨します。これにより、パーツがマージの最大サイズに達するのを防ぎやすくなり、継続的な手動最適化の必要性も減らせます。
### パーティション化とパーティションをまたぐマージ @@ -358,11 +358,11 @@ ReplacingMergeTree でパーティションを活用するで説明したよう ### クエリパフォーマンスを向上させるためのマージの調整
-デフォルトでは、min_age_to_force_merge_seconds と min_age_to_force_merge_on_partition_only はそれぞれ 0 と false に設定されており、これらの機能は無効です。この構成では、ClickHouse はパーティションの経過時間に基づいてマージを強制せず、標準のマージ動作を適用します。 +デフォルトでは、`min_age_to_force_merge_seconds` と `min_age_to_force_merge_on_partition_only` はそれぞれ 0 と false に設定されており、これらの機能は無効です。この構成では、ClickHouse はパーティションの経過時間に基づいてマージを強制せず、標準のマージ動作を適用します。 -min_age_to_force_merge_seconds に値を指定すると、ClickHouse は指定した期間より古いパーツに対して、通常のマージヒューリスティクスを無視します。これは一般に、パーツの総数を最小限に抑えることが目的の場合にのみ効果的ですが、ReplacingMergeTree ではクエリ実行時にマージ対象となるパーツ数を減らすことで、クエリパフォーマンスの向上につながる場合があります。 +`min_age_to_force_merge_seconds` に値を指定すると、ClickHouse は指定した期間より古いパーツに対して、通常のマージヒューリスティクスを無視します。これは一般に、パーツの総数を最小限に抑えることが目的の場合にのみ効果的ですが、ReplacingMergeTree ではクエリ実行時にマージ対象となるパーツ数を減らすことで、クエリパフォーマンスの向上につながる場合があります。 -この挙動は、min_age_to_force_merge_on_partition_only=true を設定することでさらに調整できます。この設定では、積極的なマージを行う条件として、パーティション内のすべてのパーツが min_age_to_force_merge_seconds で指定した時間より古くなっている必要があります。この構成により、古いパーティションは時間の経過とともに 1 つのパーツまでマージされ、データが集約されることでクエリパフォーマンスを維持できます。 +この挙動は、`min_age_to_force_merge_on_partition_only=true` を設定することでさらに調整できます。この設定では、積極的なマージを行う条件として、パーティション内のすべてのパーツが `min_age_to_force_merge_seconds` で指定した時間より古くなっている必要があります。この構成により、古いパーティションは時間の経過とともに 1 つのパーツまでマージされ、データが集約されることでクエリパフォーマンスを維持できます。 -기본적으로 min_age_to_force_merge_seconds와 min_age_to_force_merge_on_partition_only는 각각 0과 false로 설정되어 있으므로, 이러한 기능은 비활성화됩니다. 이 구성에서는 ClickHouse가 파티션 경과 시간에 따라 머지를 강제하지 않고, 표준 머지 동작을 적용합니다. +기본적으로 `min_age_to_force_merge_seconds`와 `min_age_to_force_merge_on_partition_only`는 각각 0과 false로 설정되어 있으므로, 이러한 기능은 비활성화됩니다. 이 구성에서는 ClickHouse가 파티션 경과 시간에 따라 머지를 강제하지 않고, 표준 머지 동작을 적용합니다. -min_age_to_force_merge_seconds 값을 지정하면 ClickHouse는 지정된 주기보다 오래된 파트에 대해서는 일반적인 머지 휴리스틱을 무시합니다. 이는 대체로 전체 파트 수를 최소화하는 것이 목표일 때에만 효과적이지만, 쿼리 시점에 머지해야 하는 파트 수를 줄여 ReplacingMergeTree의 쿼리 성능을 개선할 수 있습니다. +`min_age_to_force_merge_seconds` 값을 지정하면 ClickHouse는 지정된 주기보다 오래된 파트에 대해서는 일반적인 머지 휴리스틱을 무시합니다. 이는 대체로 전체 파트 수를 최소화하는 것이 목표일 때에만 효과적이지만, 쿼리 시점에 머지해야 하는 파트 수를 줄여 ReplacingMergeTree의 쿼리 성능을 개선할 수 있습니다. -이 동작은 min_age_to_force_merge_on_partition_only=true를 설정해 추가로 세부 조정할 수 있습니다. 이렇게 하면 적극적인 머지를 수행하려면 해당 파티션의 모든 파트가 min_age_to_force_merge_seconds보다 오래되어야 합니다. 이 구성에서는 오래된 파티션이 시간이 지나면서 하나의 파트로 머지될 수 있으므로, 데이터를 통합하고 쿼리 성능을 유지하는 데 도움이 됩니다. +이 동작은 `min_age_to_force_merge_on_partition_only=true`를 설정해 추가로 세부 조정할 수 있습니다. 이렇게 하면 적극적인 머지를 수행하려면 해당 파티션의 모든 파트가 `min_age_to_force_merge_seconds`보다 오래되어야 합니다. 이 구성에서는 오래된 파티션이 시간이 지나면서 하나의 파트로 머지될 수 있으므로, 데이터를 통합하고 쿼리 성능을 유지하는 데 도움이 됩니다. -Por padrão, min_age_to_force_merge_seconds e min_age_to_force_merge_on_partition_only são definidos como 0 e false, respectivamente, o que desativa esses recursos. Nessa configuração, o ClickHouse aplicará o comportamento padrão de mesclagem, sem forçar mesclagens com base na idade da partição. +Por padrão, `min_age_to_force_merge_seconds` e `min_age_to_force_merge_on_partition_only` são definidos como 0 e false, respectivamente, o que desativa esses recursos. Nessa configuração, o ClickHouse aplicará o comportamento padrão de mesclagem, sem forçar mesclagens com base na idade da partição. -Se um valor for especificado para min_age_to_force_merge_seconds, o ClickHouse ignorará as heurísticas normais de mesclagem para partes mais antigas do que o período especificado. Embora isso geralmente só seja eficaz quando o objetivo é minimizar o número total de partes, pode melhorar o desempenho das consultas no ReplacingMergeTree ao reduzir o número de partes que precisam ser mescladas no momento da consulta. +Se um valor for especificado para `min_age_to_force_merge_seconds`, o ClickHouse ignorará as heurísticas normais de mesclagem para partes mais antigas do que o período especificado. Embora isso geralmente só seja eficaz quando o objetivo é minimizar o número total de partes, pode melhorar o desempenho das consultas no ReplacingMergeTree ao reduzir o número de partes que precisam ser mescladas no momento da consulta. -Esse comportamento pode ser ajustado ainda mais definindo min_age_to_force_merge_on_partition_only=true, o que exige que todas as partes da partição sejam mais antigas do que min_age_to_force_merge_seconds para que ocorra uma mesclagem agressiva. Essa configuração permite que partições mais antigas sejam gradualmente mescladas até se tornarem uma única parte, o que consolida os dados e mantém o desempenho das consultas. +Esse comportamento pode ser ajustado ainda mais definindo `min_age_to_force_merge_on_partition_only=true`, o que exige que todas as partes da partição sejam mais antigas do que `min_age_to_force_merge_seconds` para que ocorra uma mesclagem agressiva. Essa configuração permite que partições mais antigas sejam gradualmente mescladas até se tornarem uma única parte, o que consolida os dados e mantém o desempenho das consultas. -По умолчанию для min_age_to_force_merge_seconds и min_age_to_force_merge_on_partition_only установлены значения 0 и false соответственно, поэтому эти возможности отключены. В такой конфигурации ClickHouse использует стандартное поведение слияния и не принудительно запускает слияния на основе возраста партиции. +По умолчанию `min_age_to_force_merge_seconds` и `min_age_to_force_merge_on_partition_only` имеют значения 0 и false соответственно, поэтому эти возможности отключены. В такой конфигурации ClickHouse использует стандартное поведение слияния и не запускает принудительные слияния на основе возраста партиции. -Если задано значение min_age_to_force_merge_seconds, ClickHouse будет игнорировать обычные эвристики слияния для частей старше указанного периода. Хотя обычно это имеет смысл только тогда, когда цель — минимизировать общее число частей, в ReplacingMergeTree это может повысить производительность запросов за счёт уменьшения числа частей, которые нужно сливать во время выполнения запроса. +Если задано значение `min_age_to_force_merge_seconds`, ClickHouse будет игнорировать обычные эвристики слияния для частей старше указанного периода. Хотя обычно это имеет смысл только тогда, когда цель — минимизировать общее число частей, в ReplacingMergeTree это может повысить производительность запросов за счёт уменьшения числа частей, которые нужно сливать во время выполнения запроса. -Это поведение можно дополнительно настроить, установив min_age_to_force_merge_on_partition_only=true: тогда для агрессивного слияния все части в партиции должны быть старше, чем min_age_to_force_merge_seconds. Такая конфигурация позволяет старым партициям со временем сливаться в одну часть, что консолидирует данные и помогает поддерживать производительность запросов. +Это поведение можно дополнительно настроить, установив `min_age_to_force_merge_on_partition_only=true`: тогда для агрессивного слияния все части в партиции должны быть старше `min_age_to_force_merge_seconds`. Такая конфигурация позволяет старым партициям со временем сливаться в одну часть, что консолидирует данные и помогает поддерживать производительность запросов. -在 merge 期间，ReplacingMergeTree 会识别重复行，将 `ORDER BY` 列的值用作唯一标识符，并且要么只保留最高版本，要么在最新版本表示删除时移除所有重复项。然而，这只能提供最终一致的正确性——并不能保证行一定会被去重，因此不应依赖它。因此，由于查询时会将更新行和删除行也纳入考虑，查询结果可能不正确。 +在合并时，ReplacingMergeTree 会识别重复行，将 `ORDER BY` 列的值用作唯一标识符，并且要么只保留最高版本，要么在最新版本表示删除时移除所有重复项。然而，这只能提供最终一致的正确性——并不能保证行一定会被去重，因此不应依赖它。因此，由于查询时会将更新行和删除行也纳入考虑，查询结果可能不正确。 -要获得正确结果，你需要结合 background merges，并在 query time 执行去重和删除移除。这可以通过使用 `FINAL` 运算符来实现。 +要获得正确结果，你需要结合 background merges，并在查询时执行去重和删除移除。这可以通过使用 `FINAL` 运算符来实现。 以上面的 posts 表为例。我们可以使用加载该数据集的常规方法，但额外指定 deleted 列和 version 列，并将它们的值设为 0。为了便于演示，这里我们只加载 10000 行。 @@ -125,7 +125,7 @@ SELECT count() FROM stackoverflow.posts_updateable │ 10000 │ └─────────┘ -1 行，耗时 0.002 秒。 +1 row in set. Elapsed: 0.002 sec. ``` 我们现在更新回答后的帖子统计信息。我们不直接更新这些值，而是插入 5000 行的新副本，并将它们的版本号加一 (这意味着表中将有 150 行) 。我们可以用一个简单的 `INSERT INTO SELECT` 来模拟这一过程： @@ -156,7 +156,7 @@ INSERT INTO posts_updateable SELECT ParentId, CommunityOwnedDate, ClosedDate -FROM posts_updateable --随机选取100行 +FROM posts_updateable --select 100 random rows WHERE (Id % toInt32(floor(randUniform(1, 11)))) = 0 LIMIT 5000 @@ -191,14 +191,14 @@ INSERT INTO posts_updateable SELECT ParentId, CommunityOwnedDate, ClosedDate -FROM posts_updateable --随机选取 100 行 +FROM posts_updateable --select 100 random rows WHERE (Id % toInt32(floor(randUniform(1, 11)))) = 0 AND AnswerCount > 0 LIMIT 1000 0 rows in set. Elapsed: 0.166 sec. Processed 135.53 thousand rows, 212.65 MB (816.30 thousand rows/s., 1.28 GB/s.) ``` -上述操作的结果将是 16,000 行，即 10,000 + 5000 + 1000。而这里实际正确的总数应仅比原始总数少 1000 行，即 10,000 - 1000 = 9000。 +上述操作后，结果将是 16,000 行，即 10,000 + 5000 + 1000。实际上，正确的总数应该只比原始总数少 1000 行，即 10,000 - 1000 = 9000。 ```sql SELECT count() @@ -210,7 +210,7 @@ FROM posts_updateable 1 row in set. Elapsed: 0.002 sec. ``` -这里的结果会因已发生的合并而有所不同。我们可以看到，这里的总数不一样，因为存在重复行。对表应用 `FINAL` 可得到正确结果。 +结果会因已发生的合并而有所不同。我们可以看到，由于存在重复行，总数会有所不同。对表应用 `FINAL` 可得到正确结果。 ```sql SELECT count() @@ -359,11 +359,11 @@ ClickHouse 中的 ReplacingMergeTree 引擎经过优化，可通过合并 parts ### 调优合并以提升查询性能 -默认情况下，min_age_to_force_merge_seconds 和 min_age_to_force_merge_on_partition_only 分别设置为 0 和 false，因此这些功能默认处于禁用状态。在这种配置下，ClickHouse 会采用标准的合并行为，不会根据分区的时间强制执行合并。 +默认情况下，`min_age_to_force_merge_seconds` 和 `min_age_to_force_merge_on_partition_only` 分别设置为 0 和 false，因此这些功能默认处于禁用状态。在这种配置下，ClickHouse 会采用标准的合并行为，不会根据分区的时间强制执行合并。 -如果为 min_age_to_force_merge_seconds 指定了值，ClickHouse 将对早于该时间阈值的 parts 忽略常规的合并启发式规则。虽然这种做法通常只在目标是尽量减少 parts 总数时才有明显效果，但在 ReplacingMergeTree 中，它可以通过减少查询时需要合并的 parts 数量来提升查询性能。 +如果为 `min_age_to_force_merge_seconds` 指定了值，ClickHouse 将对早于该时间阈值的 parts 忽略常规的合并启发式规则。虽然这种做法通常只在目标是尽量减少 parts 总数时才有明显效果，但在 ReplacingMergeTree 中，它可以通过减少查询时需要合并的 parts 数量来提升查询性能。 -还可以通过设置 min_age_to_force_merge_on_partition_only=true 进一步调优这一行为。这样一来，只有当分区中的所有 parts 都早于 min_age_to_force_merge_seconds 时，才会执行更激进的合并。这种配置可使较旧的分区随着时间推移逐步合并为单个 part，从而整合数据并维持查询性能。 +还可以通过设置 `min_age_to_force_merge_on_partition_only=true` 进一步调优这一行为。这样一来，只有当分区中的所有 parts 都早于 `min_age_to_force_merge_seconds` 时，才会执行更激进的合并。这种配置可使较旧的分区随着时间推移逐步合并为单个 part，从而整合数据并维持查询性能。