GCP 數據
打破 CAP 定理的全球分散式資料庫：Cloud Spanner 與 AlloyDB 實踐
打破 CAP 定理的全球分散式資料庫：Cloud Spanner 與 AlloyDB 實踐
Cloud Spanner 是 Google Cloud 的全球分散式關聯式資料庫，靠自研的 TrueTime 全球時鐘技術，讓橫跨多地域的交易仍能維持強一致性與高可用性，逼近分散式系統理論裡「CAP 定理」認為難以兩者兼得的極限。AlloyDB 則是另一種定位：高度相容 PostgreSQL 的企業級資料庫，透過 AlloyDB AI 整合向量搜尋與生成式 AI 能力，適合既有 PostgreSQL 應用程式想要效能升級的場景。
這篇會先講 CAP 定理這個老問題，再看 Spanner 怎麼靠 TrueTime 逼近全都要，接著講 Spanner Graph 的圖與向量搜尋能力，最後把 AlloyDB 拉進來一起比較，講清楚兩者怎麼分工。
你將學到什麼
CAP 定理是什麼老問題？
分散式系統面對網路分區時，一致性與可用性很難同時做到滿分，這是理論上證明過的限制，不是工程沒做好。
TrueTime 怎麼逼近極限？
結合 GPS 訊號與原子鐘替每筆交易加上精準時間戳記，讓跨地域讀到的資料一律是最新已提交的狀態。
Spanner Graph 疊加向量搜尋
在既有關聯式資料表上直接建圖，還能做 KNN 精確搜尋與 ANN 近似搜尋，適合 GraphRAG 場景。
AlloyDB 的定位
高度相容 PostgreSQL，既有驅動程式與工具鏈大多能直接沿用，並透過 AlloyDB AI 整合向量搜尋與生成式 AI。
CAP 定理不是選擇題外的裝飾，是 Cloud Spanner 整套設計都在回應的核心限制，理解這一點，才看得懂 TrueTime 到底解決了什麼問題。
CAP 定理到底在說什麼，為什麼資料庫設計繞不過它？
CAP 定理討論的是分散式系統的三個特性：
- 一致性（Consistency）：所有節點在同一時間點看到的資料都相同，沒有新舊版本並存的情況。
- 可用性（Availability）：系統持續回應請求，即使部分節點故障也不會整個服務中斷。
- 網路分區容忍（Partition tolerance）：就算節點之間的網路連線中斷，系統仍要能運作，這在跨地域部署裡幾乎是必然會發生的情況。
CAP 定理說的是，當網路分區真的發生時，系統只能在一致性與可用性之間選一個優先，沒有辦法兩者同時滿分，這是理論上證明過的限制，不是工程師偷懶。
傳統上很多分散式資料庫的做法，是在設計時先選邊站：要嘛優先保證可用性、接受資料短暫不一致；要嘛優先保證一致性、接受系統在網路分區時部分不可用。
Cloud Spanner 想做的，是把「網路分區真的發生」這件事的機率與影響壓到極低，讓系統在絕大多數運作時間裡，同時維持強一致性與高可用性，而不是在設計初期就先認輸選邊站。
Spanner 怎麼靠 TrueTime 同時做到強一致性又高可用？
TrueTime 是 Google 自研的全球時間同步服務，結合 GPS 訊號與原子鐘，讓分散在世界各地的伺服器對「現在幾點」有一致且誤差極小的認知。
技術細節上，TrueTime 提供的不是一個單一時間點，而是一個帶有明確誤差範圍的時間區間，Spanner 在提交交易時會刻意等待，直到確定這個時間區間已經真正過去（業界稱為 commit wait），藉此保證即使誤差存在，不同節點對「這筆交易發生的先後順序」也不會產生歧義。這也是為什麼 TrueTime 需要仰賴 GPS 與原子鐘這類高精度時間源：時間誤差被壓得越小，commit wait 需要等待的時間就越短，交易延遲也越低。
Spanner 靠這個機制替每筆交易加上精準的提交時間戳記，藉此做到外部一致性：任何節點讀到的資料，都反映最新已提交的狀態，不會出現跨地域讀到舊資料的情況。
這套設計讓 Spanner 被官方定位為「always-on、可橫向擴展到近乎無上限」的資料庫，同時保有傳統 SQL 資料庫熟悉的 ACID 特性，這在全球分散式系統裡並不常見。
CAP 定理是數學上證明過的限制，Spanner 沒有真的違反它，而是靠 TrueTime 把網路分區的機率與影響壓到極低，逼近理論上很難兩全的目標。業界常用「挑戰」或「逼近」來形容，比較貼近技術現實，這也是這篇文章想澄清的地方。
在關聯式資料庫上建圖，跟專用圖資料庫有什麼不同？
Spanner Graph 不是另外一個獨立產品，而是建立在既有 Cloud Spanner 資料表之上的一層圖形查詢能力，你可以在既有關聯式資料表上定義節點與邊，也支援不用預先定義完整綱要的彈性建模方式。
官方後續也把 Spanner Studio 做成能視覺化建立與管理圖形綱要，用拖拉節點與邊的方式設計，取代手寫一長串 DDL 語句。
更進一步的是向量搜尋整合：Spanner Graph 支援 KNN 精確搜尋與 ANN 近似搜尋，可以用餘弦距離、歐氏距離、內積等多種距離函數，適合 GraphRAG 這類把知識圖譜與向量檢索結合的生成式 AI 應用場景。ANN 搜尋需要另外建立專用向量索引，且目前僅支援節點層級的搜尋，不含邊。
典型的應用情境包括供應鏈追溯（一筆原料經過哪些加工節點才變成成品）、社群網路裡的關聯分析（誰認識誰、透過幾層關係連接），或是把知識圖譜跟向量搜尋結合的 GraphRAG：先用圖結構做精確的關聯查詢，再用向量搜尋補上語意相近但沒有明確連結的內容。跟獨立部署一套專用圖資料庫比起來，這種做法省下維護另一套系統與資料同步的成本，代價是圖形查詢的進階功能通常不如專用圖資料庫齊全，要看場景複雜度取捨。
AlloyDB 跟一般 PostgreSQL 服務差在哪裡？
AlloyDB 定位完全不同，它是高度相容 PostgreSQL 的企業級資料庫服務，官方宣稱效能經過針對 Google Cloud 基礎設施的最佳化，具體效能倍數請以官方最新測試方法與公告為準。
架構上，AlloyDB 採用儲存與運算分離的設計，並在同一份資料上疊加一層欄式（columnar）快取，讓分析型查詢不用另外搬到獨立的資料倉儲，就能在同一個資料庫裡有不錯的分析效能，這也是它宣稱「相容 PostgreSQL 又比原生 PostgreSQL 更快」的架構基礎。
相容 PostgreSQL 的意義在於，既有的應用程式、驅動程式與工具鏈大多可以直接沿用，不用為了換資料庫重寫一整套資料存取層，這也是很多團隊評估遷移時最看重的一點。
| 面向 | Cloud Spanner | AlloyDB |
|---|---|---|
| 核心定位 | 全球分散式強一致性資料庫 | 高度相容 PostgreSQL 的企業級資料庫 |
| 一致性模型 | 靠 TrueTime 做到跨地域外部一致性 | 標準 PostgreSQL 交易一致性模型 |
| 典型情境 | 全球規模、跨地域交易的核心系統 | 既有 PostgreSQL 應用程式的高效能升級 |
| 圖與向量能力 | Spanner Graph 內建圖與向量搜尋 | AlloyDB AI 提供相容 pgvector 的向量搜尋 |
AlloyDB AI 跟 AlloyDB Omni 差在哪裡？
AlloyDB AI 是功能層的延伸，把生成式 AI 能力整合進資料庫本身：
- 相容 pgvector 擴充套件的向量搜尋。
- 結合關鍵字與向量相似度的混合搜尋。
- 把日常語言提示轉成可執行 SQL 查詢的自然語言查詢能力，目前部分功能仍在預覽階段。
- 時間序列預測、自帶機器學習模型（BYOML），以及外部模型端點管理。
AlloyDB Omni 則是部署層的延伸，讓你能在地端或其他雲端環境跑一套與 Google Cloud 版本功能對齊的 AlloyDB，2026 年的更新包含支援較新的 PostgreSQL 版本，以及預覽階段的靜態加密（TDE）能力，適合有混合雲或資料主權考量的企業場景。
AlloyDB AI 是功能，AlloyDB Omni 是部署位置，兩者不衝突。在地端部署的 Omni 上，一樣能用到 AlloyDB AI 的相關功能，不必因為選了地端部署就放棄向量搜尋與生成式 AI 這些能力。
該選 Spanner 還是 AlloyDB？
- 需要跨地域、全球規模的強一致性交易嗎？ 有的話往 Cloud Spanner 想，這是它設計初衷要解決的問題。
- 手上已經有一套成熟的 PostgreSQL 應用嗎？ AlloyDB 的相容性設計，讓遷移路徑相對平順，不用重寫資料存取層。
- 需要在關聯式資料上疊加圖形查詢與向量搜尋嗎？ Spanner Graph 把這兩件事整合在同一個資料庫裡，省下維護獨立圖形資料庫的力氣。
- 有資料主權或混合雲的限制嗎？ 這種情境下 AlloyDB Omni 值得認真評估，能在地端維持與雲端一致的功能集。