Google發布Spanner論文，宣告重回分布式事務語義

　　英文原文：Google Publishes Paper On Spanner Ushering a Return to Distributed Transactional Semantics

　　上個月，在 Operating System Design and Implementation（OSDI '12）大會上，Google 放出了 Spanner 的詳細信息——Spanner 是一個高可伸縮、全球復制的半關系型數據庫。上周，Google 又給出了論文合著者 Wilson Hsieh 的一個與 OSDI 2012 上演講相關的視頻，該視頻專注于論文里的一些關鍵概念，InfoQ 的 Alex Popescu 發表了一篇文章，內容是 Berlin Buzzwords 上 Alex Lloyd 提供的更多詳細信息。研究證明 ACID 語義不需要犧牲高可伸縮性，推翻了 NoSQL 是高可伸縮性持久化的萬靈藥的想法。論文中的這句話很好地表明了這一觀點：

我們認為，最好是讓應用程序開發者在出現瓶頸時處理由事務使用過度引起的性能問題，而非總是在缺少事務的情況下進行編碼。

　　Spanner 項目源于 Google Adwords 系統在持久化方面的需要，該解決方案既要滿足關系型與事務性，同時又要在全球范圍內可伸縮部署。MegaStore 僅部分滿足這些關注點，因為在跨洲際事務時沒有可預計的延時是無法實現其一致性保障的。在 Spanner 中，分布式事務的延時問題是通過 Google 的 TrueTime API 來處理的，這基本上是一個針對時鐘不確定性（clock uncertainty）問題的解決方案。

　　通過大范圍網絡中的多個參考時間確定時鐘時間時，時鐘漂移和網絡延時會引入時鐘不確定性（在論文中用ε符號表示）。參考時間混合了 GPS 時間和原子時鐘，通過冗余降低了它們的錯誤率。通過確定影響時鐘不確定性的因素，將其上限控制在一個承諾的等待間隔里（兩倍的ε），就能實現外部一致性保證以及其他一些好處，比如無鎖讀事務、非阻塞讀以及原子 Schema 變更。因此，承諾的等待間隔直接和時鐘不確定性綁在了一起，不確定性越高，等待間隔就越長，也會拖慢 Spanner。然而，為了降低較長等待間隔（通常是 10ms，但呈現長尾分布）帶來的影響，Spanner 在等待時間里執行了 Paxos（一致協議）或兩階段提交的準備階段。

　　Spanner 的數據模型與 Megastore 類似，都是半關系型層次化結構模型。Timothy O'Brien 在O'Reilly 上的博客里對 Spanner 做了一個總結：

一套 Spanner 部署是由一些管理服務器組成的，它們是用來管理跨數據中心的多個“區域”（Zone）的。一臺“區域主服務器”（Zone master）和一系列“位置代理”（location proxy）管理了成百上千的“Spanserver”，它們是在 Spanner 數據庫中執行批量工作的。Spanserver 中存儲的數據單元稱為“目錄”（directory），每個單元中都實現了一個位于 Tablet 之上的 Paxos 狀態機。Spanserver 以B樹的形式存儲數據，使用了一個復合鍵，再結合上一個時間戳和一個值。

　　Cloudant Labs 在他們的博客里指出了 Spanner 缺少的兩塊東西：

顯然 Spanner 目前還不支持二級索引的自動處理。而且，它不支持以后能達到一致狀態的“離線”訪問（像 CouchDB 那樣的離線訪問）。

　　NuoDB 為他們的解決方案申請了專利，從他們的專利描述來看，也實現了和 Spanner 相同的功能，但 Google 宣稱 Spanner 是第一個全球復制、可伸縮的 ACID 數據庫。圍繞 NoSQL vs. NewSQL 之爭，Spanner 對您的產品和項目實現會產生何種影響呢？