上個月的 ACM Queue 趕在最後幾天刊出了 Dan Pritchett, Technical Fellow at eBay, 的一篇文章 : BASE: An ACID Alternative.
BASE ( Basically Available, Soft State, and Eventually Consistent ) 相對於傳統的 ACID 以強調 Consistency 為主, 改為採用犧牲 Consistency 來換取 Availability 的概念.
基本上 Consistency 跟 Availability 常常是唱反調的, 因為要確保 Consistency 免不了需要在每個動作之前進行妥協 ( Negotiation ) 或是動作之後的檢查, 例如經典的 Two Phase Commit ( 2PC ), 而這就會傷害到 Availability. 在 BASE 的方法中, 把 Consistency 的檢查做了延遲, 先允許部份動作的進行與 Commit, 等所有的動作完成之後再設法確認無誤.
而 BASE 的作法則是, 把交易紀錄表的更新與使用者紀錄表的更新分開, 變成數個 Transactions. 首先進行交易紀錄表的更新 Master Transaction, 然後再執行兩個更新使用者紀錄表的 Sub Transactions ( Seller 以及 Buyer ). 在 Master Transaction 中除了更新交易紀錄表之外, 事實上還發出了進行接下來數個 Sub Transactions 的要求到一個 Message Queue 中, 然後進行 Commit. 而在 Message Queue 中的 SQL Statement 則會在之後個別以 Transactions 作包裝進行 Commit.
基本概念大略是這樣, 文章後半段還有討論到 Peek Queue Message 以及 Remove Message 的細節, 以及使用 SQL Statement 作整個敘述上的簡化.
BASE 的作法當然可能在 Sub Transaction Fail 時引起 Inconsistency 的問題, 但是透過適當的 Traceback 機制, 我想應該可以快速的作 Error Recovery, 例如在 Master Transaction 送出的 Messages 上標記特殊的 Tag, 一旦出問題就可以追蹤到所有相關的 Transactions. 但是文章內容沒有對 Error Recovery 的處理部份著墨太多.
BASE 的應用關鍵我認為是在 Transaction 的結果事實上是應對到不同的使用者上, 包含 eBay 系統本身, Seller 以及 Buyer. 由於並非同一個角色, 因此在這些 Transactions 進行時所實際短暫產生的 Inconsistency 不會被三者察覺到 ( 除非 Seller 跟 Buyer 即時溝通確認 Consistency ). 而技術上來說, BASE 也沒有刻意隱藏 Temporal Inconsistency 的事實, 只是當 Seller 與 Buyer 角色分開時, 他們各自無法透過 Partial Information 去推知 Inconsistency 的發生罷了 :p -- 當然, 這也暗示了 BASE 的應用領域相較於 ACID 來說是會比較受侷限的.
從這點回頭來看這篇文章被放在這期的 ACM Queue 是很有趣的事情. May /June 這期的 ACM Queue 主題是 Object-Relation Mappers. 其他三篇文章都在講 ORM, 唯獨這篇殺出 ACID 與 Consistency/Availability 的問題. 是意外嗎 ? 或是 BASE 的方法事實上是把 eBay System 中的 Objects 與其 Behaviors, 給 Mapping 到了 Relational Database 中了 ?
This entry was posted on 上午8:25 and is filed under article comment , data and knowledge engineering . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.