Google Spanner 的論文出來了，這個名字在 Jeff Dean 10 年的一次講座中已經被提到。我到吃貨公司上班的第一天就找了它的文檔來看，現在可以吐一下憋了一年的槽了。
我假定你在看本文前已經至少看過 GFS、BigTable 和 MegaStore 的論文，否則將很難理解論文中提到的技術基礎和技術決定。這是一篇吐槽文，不是 Spanner 論文翻譯或介紹，所以也假定你已經看完了 Spanner 論文。
老實說 Google Spanner 的看點不多，可以很快地列一下。Globally distributed 的需求不是那麼容易遇到，與其各種表示牛B，期待開源版，不如在論文裏汲取營養，各取所需吧。
首先是進一步方便應用開發者。Google Spanner 提供大家熟悉的表模型（其實跟 RDBMS 的表不太是一回事），提供 SQL 支持。甚至用 two-phases commit 實現了分佈事務，這個實現理論上的新意不多（當然實現各種複雜，我這裏只是站著說話不腰疼）性能也是註定的低，關鍵是論文裏說了一句：設計討論中有的spanner開發成員擔心two-phases commit太慢太複雜，但他們的最終結論是，既然業務上避免不了，與其讓應用開發者痛苦地搞個自己的2B不靠譜實現，不如直接做個標準靠譜的，再讓應用開發者想辦法避免它的慢。
我各種贊同這個思路，做 infrastructure 要在兩個目標之間平衡，首先是支持應用開發者高效開發，其次才是保證架構可擴展，支持應用增長。為什麼是這個首先其次呢？應用開發者不爽，做不出好應用，你也別想有啥業務增長，也沒機會解決擴展性不夠好這種富人的煩惱。我一直不理解一些中小網站，放著好好的 MySQL/Postgre 和成熟的 ORM 框架不用，偏要搗鼓什麼 NoSQL, 誰來幫我解釋一下這都是為啥？
接著是數據模型。Google Spanner 的數據模型說白了就是披著 RDBMS 的樹形結構存儲。這種結構是非常符合在綫應用的常見數據模式的，分用戶、分類別…… 最後都能歸納到樹形模式 + 有限的關係運算。真正天女散花式亂 JOIN 的通常只應該在離線分析業務中遇到；而更特殊的在綫需求，例如微博的信息發佈和收聽，則應該專用需求專用系統，不應該直接用通用存儲系統涵蓋了。
樹形結構 + 輕量 RDBMS 功能，這種需求傳統上就是用 MySQL + Sharding 涵蓋的。 其實 Spanner 也沒多神奇，也是在這個思路下做得更細緻更強。值得仔細讀讀的是它怎麼把樹形結構映射到一個連續空間，怎麼（以及為什麼）把 Directory 看成基本的分佈單位。完成了這一步，剩下的問題基本上已經被 BigTable 解決過了，例如 spanner 沒有惱人的 re-sharding, 而是用 tablet 分裂來代替，實現方法在 BigTable 論文裏有非常詳細的敘述。但說到底其基本思路還是 1. 局部性原理 2. 數據分片，普通青年把這叫做 sharding，騰訊把這叫分 set，在 Spanner 不管叫啥還是這東東。
最後是 Paxos 使用和純屬作弊的 TrueTime. Spanner 要求可以實現全球高一致性同步，這個也是業務需求使然，在數據同步中引入 Paxos 同步也幾乎是必然選擇，這沒什麼好說的。分佈式事務的 two-phases commit 也是標準實現，沒什麼特別。
然則，你要做分佈式事務，並發的兩個事務你要麼想辦法處理衝突，要麼就像個辦法給他們排個先後的序。這是分佈式系統裏經典的時序問題，Spanner 提出了一個會讓 Leslie Lamport 吐血的辦法，Lamport 寫了 N 篇 brain-fu*king 級別的論文說明此事之不可強求。按 Lamport 的看法，你要在分佈式系統裏拿到全局時序，你就得用 Paxos，你搞全球 Paxos（光速是有限的，請自行計算搞一次跨洲 Paxos 要多久），這必然會成為一個性能瓶頸。可是 Jeff Dean 說，切，我弄個絕對時間，GPS + 原子鐘，這事就成了，吹咩。非常彪悍暴力的思路，工程型人士想出來的東西。不過就是 work，排臺大叫作弊之於，你也只得拜服。
好了，我看到的 Google Spanner 就是這麼多東西，都不是什麼 magic，有啟發，有無奈，請各種期待下一季。