ReplacingMergeTree 是什麼？#

ReplacingMergeTree 是 ClickHouse MergeTree 家族的一員（家族真熱鬧），它能在背景 Merge 操作時，自動根據指定欄位 (如 version 欄位) 將重複資料去除，保留最新版本或最先寫入的那一筆。

ReplacingMergeTree 的語法與範例#

1
CREATE TABLE user_profiles
2
(
3
    user_id UInt64,
4
    profile_version UInt32,
5
    name String,
6
    email String
7
) ENGINE = ReplacingMergeTree(profile_version)
8
ORDER BY user_id;

• profile_version 為版本欄位，決定在去重時保留最新版本。
• 若不指定 version，系統會隨機保留其中一筆（不保證順序），走一個俄羅斯輪盤風格。

1
INSERT INTO user_profiles VALUES (1, 1, 'Alice', '[email protected]');
2
INSERT INTO user_profiles VALUES (1, 2, 'Alice', '[email protected]');
3
INSERT INTO user_profiles VALUES (2, 1, 'Bob', '[email protected]');

查詢時可能會看到重複資料，因為去重尚未透過 Merge 發生：

1
SELECT * FROM user_profiles WHERE user_id = 1;

結果：

進行 FINAL 查詢語法後（ FINAL 確保查詢時「讀到最新去重後的結果」）：

1
OPTIMIZE TABLE user_profiles FINAL;

1
SELECT * FROM user_profiles FINAL WHERE user_id = 1;

IMPORTANT

OPTIMIZE：強制執行資料片段 (Data Parts) 合併動作，把分散的小 Data Parts 合併成大 Part，並同時觸發資料去重（ReplacingMergeTree）或聚合（SummingMergeTree）等邏輯。

實質影響的是磁碟上的 Data Parts 資料，合併結果是永久性（會寫入磁碟）。

再查詢結果只會剩下 version = 2 的那筆資料。

ReplacingMergeTree 跟 Primary Key 的關係#

• 去重是基於 Primary Key 判斷的，因此建表時的 ORDER BY 欄位（也就是 Primary Key）必須正確設計。
• 若 ORDER BY 欄位無法唯一識別一筆記錄，則 ReplacingMergeTree 可能會保留錯誤的資料版本。

1
ORDER BY (user_id, profile_version)

1
ORDER BY user_id

ReplacingMergeTree 使用時機與適用場景#

ReplacingMergeTree v.s. AggregatingMergeTree#

ReplacingMergeTree 常見誤區與最佳實踐#

ReplacingMergeTree 與去重效能影響#

• ReplacingMergeTree 的寫入效能與 MergeTree 相近，因為去重是延遲處理的，不影響寫入吞吐量。
• 背景合併 (Merge) 時會額外進行去重比對，Merge 負載會稍大，但對查詢來說，去重後反而能大幅減少掃描資料量。
• 資料去重完成後，儲存空間可獲得顯著節省（取決於重複數據比例）。

結語#

ReplacingMergeTree 提供了一種無需複雜索引或額外處理邏輯即可實現數據去重的輕量解決方案，非常適合用於 「資料流去重」、「批次匯入防重複」、「版本控制」 等場景。 然而，了解其 去重時機 與 Primary Key 設計要點 是使用這個引擎的關鍵。