再認識Google F1和Spanner

轉載于http://www.sizeofvoid.net/再認識google-f1和spanner/

F1到底是啥？Spanner的論文裡隻說它是廣告業務系統，Google在今天五月另外還發過一篇文章專門講的F1，當時沒看懂就忘了，現在重看，可以串起來了。

F1才是所謂的分布式資料庫，Spanner是它下層的k/v存儲(保證了備援分布和ACID)，二者其實是緊密結合的，上層應用的資料模型決定了下層的設計實作，因為F1以前在MySQL上就是按CustomerID做shard，是以到了Spanner裡才會有樹狀的directory，并且以directory為粒度來實作備援分布，甚至我前天沒搞明白的那個問題(為什麼不用LSM-tree而用B-tree)很可能也是指：在實體檔案的組織上采用樹狀結構來對應directory，可每個檔案本身還是LSM，因為WAL還在，而且時間戳是每條資料的必備屬性。

由于F1的那篇文章其實不是文章，隻是個PPT，隻講了WHAT，沒有講HOW，而且篇幅很短，是以各種資料庫功能實作到了什麼程度以及如何實作的，現在還隻能靠猜。但有幾點比較明确：

1) 除了樹狀主鍵外，資料本身是Protocol Buffer格式的，直接作為key-value store的value存放到Spanner裡。

2) PB格式的模型和傳統關系型的資料模型很不一樣，其field可以為略去可以重複，是以，某些從前要另外建表的場景，在PB裡可能就直接全部存一起了，譬如customer { id, name, item[*] { iid, price[?], weight[?], size[?]} }，這樣，它就用資料的備援來避免了JOIN和外鍵的需求。雖然分布式場合下，資料多存幾遍多占些記憶體和硬碟空間已經不是問題，可備援資料在需要更新的時候還是很麻煩，估計目前F1的場景裡很少有這樣的需求。

3) 他們自己也承認，基于這樣的資料模型來實作的SQL，隻是看着眼熟而已，如果真像傳統SQL那麼用，一些隐含的JOIN操作或周遊請求會使性能非常糟糕，但他們是Google，他們可以說這是ORM本身的問題 (“These hurt performance in all databases. They are disastrous on F1″)，是以目前他們自己用的F1用戶端的庫也限定了使用者不能使用join，所有資料都必須顯式地讀取。

4) 是以，也許F1的确做到了傳統資料庫的功能，但它是基于完全不同的資料模型，這非常容易被誤會，以為Google創造了和我們所了解的“資料庫”一樣的東西同時還具有自動擴充以及分布式備援。世界不是那麼美好的，Oracle的人也不是笨蛋，如果能做到，他們難道不想做或能力不夠麼。工程師作為搞技術的而不是搞市場或銷售的人，要實事求是，Google首先有問題，亂用術語，動不動就Database或是SQL，真覺得是在博眼球，從文章裡也可以看出來，F1和Spanner的兩篇，提到對方的時候都說的不清不楚，好像都是自己更重要，作者署名裡也完全沒有重疊，完全是兩個團隊。他們這樣做無可厚非，可我們外面的技術人員跟着起哄就沒必要了。

最後還要說明一點，雖然Dremel也是基于PB資料格式的類SQL，但它和F1絕對是兩碼事，因為Dremel把PB的資料“列化”了，不光是列化後友善類SQL處理，甚至實際實體存儲也列化了；而F1并沒有打散PB的内容，也沒有什麼repetition level或definition level，它就是把PB資料放到key-value store的value裡，然後在key上做“樹狀化”，也就是directory。這兩個是對分布式資料處理問題的的兩種實作。

再回到實際一點的問題，上面那些都是Google的東西，不是大家的，那麼開源界能做什麼？

如果不是跨資料中心備援，Paxos狀态機組和TrueTime真沒必要。如果暫時抛開這個需求，隻說在本地的多行操作一緻性，目前HBase的做法和Spanner其實已經很像，都是通過對相同key字首的資料聚合來實作(HBASE-5368)，跨表操作的一緻性其實原理上不難，也隻能這麼做，就像Spanner裡的每個tablet組之上的transaction manager，HBase本來就用了ZooKeeper，估計也是因為需求不緊迫，也沒有人去評估這樣做的性能影響。

至于類SQL，關鍵還是使用HBase的人，如果我們現在就把PB的資料存進HBase會怎麼樣？能通過coprocessor設計出類似SQL的接口嗎？性能會不會很差？這個話題太大了，要好好琢磨琢磨，Google目前的文章裡還沒有講到他們是如何實作這一段，也沒講他們實作到什麼程度，接下來看開源界會不會有類似的讨論。