隨筆檔案

Google在SIGMOD 2008上透露了Megastore部分實現細節，詳情參考大牛James Hamilton的blog：perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx
大牛的文章固然不錯，不過肯定不大好懂，下面我說一下我對文章的翻譯+理解：
1. Google Bigtable只支持最簡單的insert, update, del, ...等函數調用API，不支持SQL形式的API，這個轉換工作放到了Megastore層次上來做。SQL對于異步Bigtable調用的支持需要仔細考慮。
2. 對于索引支持文章中已經說得很明顯了，維護一個<索引，row_key>的索引表，更新時先更新數據表再更新索引表，索引項越多，更新效率越低，但是讀基本不怎么影響，特別適合互聯網這種讀/寫比例一般超過10倍的應用。
3. Megastore不提供通用的分布式事務支持，分布式事務僅僅限于同一個entity group。Bigtable支持單行的事務，而Megastore支持row key前綴相同的多行事務，如一個用戶的blog, post, photo，可以將它們存在到Bigtable的一張表中，row key為user_id + blog_id + post_id + photo_id，這樣同一個user的數據即為一個entity group。然而，這樣就導致不能支持像百付寶、支付寶等電子商務轉賬事務，我暫時也還不清楚支持同一個entity group內部的事務意義有多大，即有多少web應用需要這種同一個entity group下的事務支持。
4. Megastore支持事務的方式當然還是傳統的Two-phase commit協議，為了解決這個協議中協調者失效導致的問題，引入Paxos協議(Google Chubby)使協調者不再成為單點。具體做起來會非常復雜，這里提供超級大牛Jim Gray和Lamport的一篇論文供大家參考：scholar.google.com/scholar   個人認為Oracle的事務內部是一個基本的Two-phase commit協議，協調者宕機時由Oracle DBA手工介入，由于其復雜性，對DBA要求很高，所以Taobao一直網羅國內頂級DBA牛人。
5. Megastore具體事務實現時會借用Bigtable 原有的機制來實現commit log, replication等功能。可能的實現為：建一張專門的Entity group root表，加載Entity group root表的Tablet Server做為協調者角色進行分布式事務控制。然而問題在于加載Entity group root表的Tablet Server是一個單點，實現多個Tablet Server服務同一個Bigtable Tablet又是一件極其困難的事情。
6. Megastore不支持復雜的Join操作，這和互聯網公司應用性質相關。Join操作一般不要求強一致性，可以通過多表冗余方式實現。
7. 事務的并發控制采用最優控制策略。簡單來說，就是事務過程中不要鎖住其它事務操作，提交的時候看一下是否與其它事務沖突，如果有沖突則重試。Megastore實現時沒有rollback，失敗了都是retry，宕機了就回放操作日志。
8. Megastore/Bigtable的實現者認為讓用戶自己指定entity group, locality group是合理的（和數據存儲位置相關)。這樣的效果是同一個entity group的數據經常存放在一臺機器上，分布式事務的性能損耗較小，這也就說明在分布式系統中，沒有代價的scalable是不存在的，要想獲得scalable和性能，就必須犧牲關系數據庫的一些特性及用戶的易用性。

上述均為個人的粗淺看法，如何避免協調者的單點等很多問題還沒有想清楚，Bigtable和Megastore的replication策略看起來也有些沖突，想清楚后將續寫！