在大數據分析中，排序查詢是最常見但也最消耗資源的操作之一。特別是當數據量達到TB級別時，傳統的排序操作往往需要數分鐘甚至更長時間。今天，我們將深入探討ClickHouse的投影（Projection） 機制，看看它是如何通過空間換時間的策略，將排序查詢性能提升數十倍的。

問題場景：以太坊賬戶余額排序

假設我們有一個包含數億條記錄的以太坊賬戶表，需要頻繁執行如下查詢：

SELECT * FROM ethereum.accounts 
ORDER BY balance_gwei DESC 
LIMIT 1000 OFFSET 10;

在傳統方案下，每次執行這個查詢都需要：

1. 掃描全表數據

2. 在內存中對數億條記錄進行排序

3. 應用LIMIT和OFFSET

4. 返回結果

這個過程不僅消耗大量CPU和內存，而且響應時間難以滿足實時分析需求。

投影機制：空間換時間的藝術

什么是投影？

投影是ClickHouse中的一種數據冗余存儲機制，它允許我們為同一份數據創建不同的物理排序方式。簡單來說，投影就是預先按指定字段排序的數據副本。

核心優勢

• 查詢透明：應用層無需修改代碼

• 自動選擇：ClickHouse優化器自動選擇最優投影

• 實時同步：新插入數據自動同步到投影

• 存儲高效：相比物化視圖，存儲開銷更小

實戰：為余額排序創建投影

步驟1：環境準備

由于我們使用ReplacingMergeTree引擎，需要先調整相關設置：

ALTER TABLE ethereum.accounts 
MODIFY SETTING deduplicate_merge_projection_mode = 'drop';

這個設置允許在數據去重過程中正確處理投影。

步驟2：創建余額投影

ALTER TABLE ethereum.accounts 
ADD PROJECTION projection_balance_gwei
(
    SELECT *
    ORDER BY balance_gwei
);

重要說明：投影定義中的ORDER BY只指定排序字段，不能使用DESC關鍵字。ClickHouse會在查詢時自動處理排序方向。

步驟3：物化投影數據

ALTER TABLE ethereum.accounts 
MATERIALIZE PROJECTION projection_balance_gwei;

對于TB級數據，這是一個后臺異步過程，可能需要數小時到數天才能完成。在此期間，系統仍然可以正常處理查詢。

步驟4：監控投影狀態

 SELECT 
    name,
    bytes,
    rows
FROM system.projection_parts 
WHERE table = 'accounts' AND database = 'test_ethereum' and name = 'projection_balance_gwei';

步驟4：檢查物化進度

-- 檢查物化進度
SELECT 
    mutation_id,
    command,
    is_done,
    parts_to_do,
    parts_done
FROM system.mutations 
WHERE table = 'accounts' AND database = 'ethereum';

驗證投影優化效果

測試查詢性能

啟用投影優化設置，驗證查詢是否使用投影：

EXPLAIN PLAN
SELECT *
FROM ethereum.accounts
ORDER BY balance_gwei DESC 
LIMIT 1000 OFFSET 10
SETTINGS allow_experimental_projection_optimization = 1, 
         force_optimize_projection = 1;

執行計劃分析

當投影優化生效時，執行計劃顯示：

Expression (Project names)
  Limit (preliminary LIMIT (without OFFSET))
    Expression
      ReadFromMergeTree (projection_balance_gwei)

這表明查詢直接從已排序的投影數據中讀取，完全避免了運行時排序操作。

如果投影尚未完全物化，可能會看到混合執行計劃：

Union
  ReadFromMergeTree (ethereum.accounts)          -- 未物化部分
  ReadFromMergeTree (projection_balance_gwei)     -- 已物化部分

隨著物化進度推進，查詢性能會逐步提升。

投影的工作原理

數據存儲機制

投影在物理層面創建獨立的數據結構：

ethereum.accounts/
├── primary/                    # 主表數據
│   ├── data.bin               # 按主鍵排序
│   └── index.bin
├── projection_balance_gwei/    # 投影數據
│   ├── data.bin               # 按balance_gwei排序
│   └── index.bin

智能排序方向處理

雖然投影內部按balance_gwei ASC存儲數據，但ClickHouse能夠智能處理降序查詢：

-- 投影數據存儲：[100, 200, 300, 400, 500] (升序)
-- 查詢：ORDER BY balance_gwei DESC LIMIT 3
-- ClickHouse會從末尾反向掃描，返回：[500, 400, 300]

查詢路由機制

當執行排序查詢時，ClickHouse優化器：

1. 分析查詢的排序字段和條件

2. 檢查是否存在匹配的投影

3. 自動選擇最優的數據源

4. 執行查詢，可能結合投影和主表數據

性能對比

實際應用建議

適用場景

• ? 頻繁的排序查詢（如排行榜、Top N分析）

• ? 數據更新不頻繁的表

• ? 存儲空間充足的環境

• ? 需要亞秒級響應的排序查詢

注意事項

• ?? 存儲開銷：投影會占用額外存儲空間（通常為原表的100-150%）

• ?? 初始物化時間：TB級數據需要數小時到數天的處理時間

• ?? 寫入性能：新數據插入時需要同步更新投影

• ?? 版本兼容：確保ClickHouse版本支持投影功能

生產環境最佳實踐

1. 選擇關鍵字段：只為最頻繁排序的字段創建投影

2. 低峰期物化：在業務低峰期觸發初始物化

3. 監控資源：關注物化過程中的CPU和I/O使用

4. 漸進式實施：先為核心業務創建投影，逐步擴展

總結

ClickHouse的投影機制為海量數據排序查詢提供了優雅的解決方案。通過預先按業務需要的維度組織數據，投影能夠：

• 消除運行時排序開銷

• 大幅降低內存和CPU消耗

• 提供亞秒級查詢響應

• 保持查詢接口的透明性

雖然需要額外的存儲空間和初始處理時間，但對于讀多寫少、需要快速排序分析的場景，投影帶來的性能收益遠遠超過其成本。

在你的下一個大數據項目中，當面臨排序性能瓶頸時，不妨考慮使用ClickHouse投影機制，體驗從分鐘級到秒級的性能飛躍。