2026 年分散式 SQL 資料庫實戰：CockroachDB 與 TiDB 的跨節點架構評估
值得注意的是 CockroachDB 對時間的處理。它使用混合邏輯時鐘（Hybrid Logical Clock, HLC），把實體時間與邏輯計數結合，為每筆交易賦予單調遞增的時間戳。這個設計讓它能在不依賴外部時間同步服務的前提下，實現外部一致性（External Consistency）。交易隔離等級預設是 Serializable，這是最嚴格的層級，代價是可能出現較多交易重試；2026 年的版本也支援 Read Committed，讓開發者能依照場景在一致性與吞吐量之間取捨。
儲存引擎方面，CockroachDB 採用自家開發的 Pebble，一個用 Go 語言實作的 LSM-tree 引擎。Pebble 在延遲穩定性與壓縮效率上持續優化，尤其針對多區域部署時的高寫入延遲場景做了不少調校。由於每個節點都是對等的，CockroachDB 沒有「腦裂」風險，也不需要額外部署協調服務，這讓它的部署拓撲相對單純。
地理分區與資料在地化策略
CockroachDB 最被稱道的功能之一是地理分區（Geo-Partitioning）。管理員可以透過 SQL 語法，依照資料列中的某個欄位（例如地區代碼）把資料釘在特定區域的節點上。例如訂單表可以設定「歐洲訂單只存在歐洲節點、亞洲訂單只存在亞洲節點」，如此一來，歐洲用戶的讀寫請求就在本地完成，完全不必跨越大西洋。
更進一步的是「生存目標」（Survival Goal）設定。你可以指定系統要能承受區域級故障還是節點級故障。如果設定為 Region Survival，CockroachDB 會確保每個 Range 的複本分散在不同區域，即使整個區域斷線，系統仍能自動恢復並繼續服務。這種把容錯目標直接寫進資料庫設定的做法，大幅簡化了跨區域架構的設計複雜度，也讓合規團隊更容易驗證資料主權要求是否被滿足。
TiDB 架構核心：TiKV、PD 與 TiFlash 的協同運作
TiDB 的架構思路與 CockroachDB 有本質差異。它採取的是「計算與儲存分離」的經典分散式設計，把 SQL 解析、分散式執行、事務協調、儲存、調度全部拆成獨立元件。這種拆分帶來了更靈活的擴展策略，也讓 TiDB 在 HTAP 場景中具備獨特優勢。
儲存層與計算層分離的優勢
TiDB 的核心元件包括：無狀態的 TiDB Server 負責接收 SQL 請求、生成分散式執行計畫；PD（Placement Driver）負責全域時間戳分配與 Region 調度；TiKV 負責行式資料儲存，底層使用 RocksDB。每個 Region 預設約 96MB，同樣透過 Raft 維持多副本一致性。
計算與儲存分離的最大好處是擴展維度獨立。當查詢壓力大時，你可以只加 TiDB Server；當資料量或寫入壓力大時，只加 TiKV 節點。這在實務上非常實用，因為不同業務階段的瓶頸往往不同。相對地，CockroachDB 的每個節點都同時承擔 SQL 與儲存職責，擴展時兩者一起增加，粒度較粗，但也換來了更簡單的維運模型。
PD 是 TiDB 架構中比較特別的存在。它負責兩件關鍵任務：一是提供全域單調遞增的時間戳（TSO），作為交易排序的依據；二是監控各 Region 的負載與分佈，自動觸發 Region 分裂、合併與遷移。PD 本身也是一個 Raft 群組，通常是三節點或五節點部署，確保調度服務本身的高可用。由於 TSO 是集中式分配，在超大規模叢集下，PD 的網路往返可能成為延遲的一部分，這是 TiDB 在跨區域部署時需要特別留意的環節。
HTAP 雙引擎與 MPP 執行模式
TiDB 在 HTAP 上的殺手鐧是 TiFlash。TiFlash 是列式儲存引擎，透過 Raft Learner 機制從 TiKV 即時同步資料，本身不參與寫入投票，因此不會拖慢交易路徑。當查詢涉及大範圍掃描或聚合分析時，TiDB 的最佳化器可以自動判斷是否將部分計畫下推到 TiFlash，甚至使用 MPP（Massively Parallel Processing）模式，讓多個 TiFlash 節點並行處理同一筆查詢，再把結果彙總回 TiDB Server。
這意味著同一個 TiDB 叢集裡，交易走 TiKV、分析走 TiFlash，彼此資源隔離，不必再維護一套獨立的資料倉儲與 ETL 流程。對於需要即時報表、即時風控或營運儀表板的場景，這個架構的價值極高。CockroachDB 雖然也能應付部分分析查詢，但在大規模列式掃描與 MPP 並行方面，TiDB 的雙引擎設計確實更為專門。
跨節點架構深度對比
理解了兩者的基本架構後，我們可以從幾個實戰最關心的維度進行對比。以下的分析基於 2026 年的版本特性與生產環境觀察。
共識機制與延遲表現
兩者都使用 Raft 作為共識演算法，也都把資料切成多個複製群組，但細節設計影響了延遲表現。CockroachDB 的 Leaseholder 機制讓讀取可以繞過共識投票，直接由本地 Leaseholder 回應，這對讀多寫少的場景非常有利。寫入則必須經過 Raft 多數派確認，跨區域寫入的延遲下限取決於複本之間的網路往返時間。
TiDB 的寫入同樣走 Raft，但讀取路徑需要向 PD 取得 TSO 或依賴本地快取的時間戳區間。在單一區域內，兩者延遲差距不大；但在跨區域部署時，CockroachDB 因為沒有集中式 TSO，且可以透過地理分區把 Leaseholder 固定在本地，通常能取得更穩定的低延遲讀取。TiDB 則可以透過部署多組 PD 或使用本地時間戳快取來緩解，但架構上仍需要更細緻的網路規劃。
擴展性與熱點處理
TiDB 在擴展性上的一個結構性優勢是 PD 的主動調度能力。PD 會根據 Region 的讀寫熱度、大小、節點負載等指標，自動觸發分裂與遷移，把熱點 Region 分散到不同節點。這對於有明顯熱點寫入的場景（例如搶購活動、IoT 時序資料）幫助很大。TiKV 的 Region 較小（96MB），調度粒度更細，熱點消解速度通常更快。
CockroachDB 的 Range 較大（512MB），調度頻率較低，但每個 Range 的 Leaseholder 可以承載更多讀取流量。面對熱點，CockroachDB 依賴 Range 分裂與 Leaseholder 轉移來處理，機制成熟但粒度較粗。在極端熱點場景下，TiDB 的自動調度通常表現得更靈活；而在讀取密集且分佈均勻的場景，CockroachDB 的較大 Range 反而減少了中繼資料開銷。
交易模型與隔離等級
這是兩者差異最明顯的地方之一。CockroachDB 預設使用 Serializable 隔離等級，並透過時間戳排序與交易重試機制來保證可序列化。這對開發者來說是最安全的預設值，但應用程式必須正確處理重試（Retry）邏輯，否則在高衝突場景下可能出現交易失敗率上升。2026 年的版本提供了 Read Committed 選項，讓開發者能依照業務容忍度調整。
TiDB 預設提供 Snapshot Isolation（快照隔離），在悲觀鎖模式下能避免多數寫寫衝突，且不太需要應用層處理重試。它同時支援樂觀鎖模式，適合衝突少的場景以換取更高吞吐量。對於從 MySQL 遷移過來的應用，TiDB 的交易行為更接近原有習慣，學習曲線較平緩；而 CockroachDB 的 Serializable 預設則需要團隊對分散式交易有更深入的理解。
生態系與工具鏈
CockroachDB 在協議相容性上選擇了 PostgreSQL，這讓它能承接大量既有的 Postgres 生態工具。備份還原、變更資料捕獲、監控指標等方面都有官方與社群方案，整體工具鏈完整但相對封閉。
TiDB 則以 MySQL 協議為核心，這是它極具戰略眼光的一步。全球絕大多數 Web 應用與中介軟體都圍繞 MySQL 生態建立，TiDB 讓這些應用幾乎可以無痛遷移。TiDB 的工具鏈极为豐富：TiUP 負責部署與運維、TiCDC 處理變更捕獲、Dumpling 與 Lightning 負責匯入匯出、TiDB Dashboard 提供視覺化監控。對於已經深度使用 MySQL 技術棧的團隊，TiDB 的吸引力顯而易見。
實戰案例：電商與金融場景的部署經驗
架構圖看再多，都不如實際跑一遍來得真切。以下整理幾個 2025 至 2026 年間常見的部署場景與觀察。
跨區域部署的拓撲設計
以一個服務亞太與歐洲用戶的電商平台為例，若選擇 CockroachDB，典型拓撲是在新加坡、東京、法蘭克福各部署三個節點，總共九節點。透過地理分區把用戶、訂單、庫存等資料依地區釘在對應區域，並設定 Region Survival 目標。結果是亞太用戶的讀寫延遲穩定在 5 至 15 毫秒，歐洲用戶同樣如此，跨區交易雖有較高延遲但頻率極低，整體體驗大幅提升。
若選擇 TiDB，典型做法是在每個區域部署完整的 TiDB Server 與 TiKV 叢集，PD 則跨區域部署五節點。透過 Placement Rules 指定資料的區域分佈。這種架構的優勢是每個區域的擴展與調度相對獨立，但 PD 的 TSO 分配需要跨區通訊，必須確保 PD 節點之間的網路延遲足夠低，否則會成為寫入路徑的瓶頸。實務上會建議把 PD Leader 放在主要寫入區域，並在應用層做路由優化。
故障演練與維運觀察
在容錯演練中，CockroachDB 的區域級故障恢復表現相當平穩。當整個法蘭克福區域斷線，系統會自動將受影響 Range 的 Leaseholder 轉移到其他區域，恢復時間通常在數十秒內，且不需要人工介入。維運團隊只需要監控複本健康度與網路連線狀態。
TiDB 在節點級故障的恢復同樣迅速，PD 會自動補足缺失的 Raft 複本。但在區域級故障時，若 PD 多數派剛好受到影響，調度能力會暫時下降，直到 PD 重新選主完成。因此 TiDB 的跨區域部署需要更謹慎地規劃 PD 的拓撲，確保任何單一區域故障都不會讓 PD 失去多數派。這也是為什麼許多企業選擇把 PD 部署在三個以上區域，或採用兩地三中心等更保守的架構。
2026 年選型建議與未來展望
談完架構與實戰，最後回到最實際的問題：你該選哪一個？
何時選 CockroachDB？何時選 TiDB？
如果你的團隊以 PostgreSQL 為主要技術棧，應用場景高度全球化且對跨區域一致性有嚴格要求，並且願意接受 Serializable 交易帶來的開發調整，那麼 CockroachDB 是很自然的選擇。它的部署模型單純、地理分區功能成熟、容錯目標設定直觀，特別適合金融交易、跨國 SaaS、需要嚴格資料主權合規的場景。
如果你的團隊深耕 MySQL 生態，工作負載同時包含高頻交易與即時分析，且希望用一套系統取代 OLTP 加 OLAP 的雙軌架構，那麼 TiDB 的 HTAP 能力與豐富工具鏈會帶來更大的整體效益。它特別適合電商、遊戲、物聯網、即時風控等需要彈性擴展與即時報表的場景。此外，TiDB 的社群版開源程度較高，對於預算敏感或需要深度客製的團隊更友善。
當然，這不是非黑即白的選擇。有些企業會採用混合策略：核心帳務用 CockroachDB，分析與報表平台用 TiDB，透過 CDC 工具做資料同步。這種做法雖然增加維運複雜度，但能針對不同場景選用最適工具。
分散式 SQL 的下一步
展望 2026 年之後，分散式 SQL 資料庫有幾個明確的發展方向。首先是 AI 工作負載的整合：向量檢索、RAG 應用、即時特徵工程都對資料庫提出新需求，我們已經看到兩者都在探索原生向量索引與 AI 查詢優化的可能性。其次是 Serverless 化：按需擴縮、按用量計費的模式正在從雲端廠商向開源生態擴散，這會進一步降低分散式資料庫的採用門檻。最後是多模態支援：JSON、時序、圖形、全文檢索等能力持續被吸納進 SQL 介面，讓開發者不必為了不同資料型態引入多套系統。
無論最終選擇哪個陣營，2026 年的分散式 SQL 已經足夠成熟，能承載最嚴苛的生產環境。關鍵在於團隊是否願意花時間理解其一致性模型、調度機制與維運模式，並據此調整應用設計。分散式資料庫不是銀彈，但對於追求全球規模、高可用與即時分析的現代應用來說，它已經是最務實的基礎設施選擇。
雅寶社區的讀者若正在進行資料庫選型，建議先從一個非核心業務的小型叢集開始試點，累積運維經驗與團隊共識，再逐步推進到核心系統。分散式轉型是一場馬拉松，選對架構只是起跑，真正的勝負取決於長期的維運紀律與技術積累。