天天看點

再認識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目前的文章裡還沒有講到他們是如何實作這一段,也沒講他們實作到什麼程度,接下來看開源界會不會有類似的讨論。

f1

繼續閱讀