ACID,yield

來源:互聯網
上載者:User

ACID,yield
細節其實很多。。。1 到底什麼是ACID

首先需要說明的是,在IT領域,很多名詞在不同的上下文環境中的語義是不同的。例如某些產品宣稱支援“100% ACID”和“強一致性”等。那麼,這些名詞到底指的是什嗎?如果不結合具體的語境,我們很可能產生各種誤解。在沒有NoSQL,也更沒有NewSQL之前,我們需要關注的是資料庫產品支援的隔離等級的差異,而不需要關心它們到底實現了ACID沒有。因為ACID是資料庫產品的根本,不同產品之間的差異可以說是微乎其微。ACID最容易導致歧義的術語就是隔離等級,不同資料庫產品支援的隔離等級、SQL標準定義的隔離等級不僅在名字上有區別,在實際含義上也有區別。例如:Oracle的可序列化其實是Snapshot Isolation1;DB2的Repeatable Read其實是Serializable2。ACID中的I(Isolation)在學術界預設指的就是可序列化,要不然問題也不會複雜到研究了幾十年還有的玩。沒有了可序列化,ACID中的Consistency也自然不靠譜了。文章3和4中列出了18個資料庫產品,對比它們提供的預設隔離等級以及最高隔離等級。這裡截個圖供參考。


既然可序列化那麼重要,那資料庫為什麼還要提供比可序列化低的隔離等級?可序列化確實在資料庫不瞭解應用程式邏輯的情況保證資料一致性的問題。但是它是要付出代價的,往往會導致系統的效能損失。較低的隔離等級可以提高效能、可用性,也能滿足應用的很多需求。例如,在基於封鎖實現的系統中,讀可以加短鎖,從而使得事務不容易死結或復原。當然了,低隔離等級會導致各種各種的一致性異常2。既然存在這麼多的問題,那為什麼低隔離等級用得還很多呢?文章3說One possibility is that anomalies are rare and the performance benefits of weak isolation outweigh the cost of inconsistencies. Another possibility is that applications are performing their own concurrency control external to the database; database programmers can use commands like SELECT FOR UPDATE, manual LOCK TABLE, and UNIQUE constraints to manually perform their own synchronization. 這個解釋比較符合應用開發中的實際情況。

2 高可用事務而不是CAP

文章3是VLDB2014的論文。題目"Highly Available Transactions: Virtues and Limitations"是應該仿照" J. Gray. The transaction concept: Virtues and limitations. In VLDB 1981."起的。它考慮的是這種情境:

  1. 廣域網路環境下的HA,文章強調網路故障(網路磁碟分割)以及時延,而且實驗環境也是Amazon上的LevelDB。
  2. 多副本,所以保證你不了可序列化。只能在弱一些的隔離等級上做。

資料庫的隔離等級和分布式系統的副本一致性(transactional isolation, replica consistency)在概念上不太統一,它將這些概念以及高可用系統統一考慮。這樣至少可以幫我們解決前面提到的術語含義問題。網路磁碟分割時可序列化是做不到的:Indeed, serializable transactions—the gold standard of traditional ACID databases—are not achievable with high availability in the presence of network partitions [.27]. 不考慮HA時,傳統的分布式可序列化和SI機制:We have a strong understanding of weak isolation in the single-server context from which it originated [2, 11, 37] and many papers offer techniques for providing distributed serializability [13, 24, 26, 41, 60] or snapshot isolation [42, 58]. 這些系統實際上也是有各種各樣的前提條件的。

什麼是HA,論文第4節對此做出了定義:HA,Sticky A,Transactional A。定義Sticky A時又引入了全複製系統和不完全複製系統的概念。實際系統大部分都是不完全複製的。按照腳註的說明,sharding系統應該屬於不完全複製的特例(每個資料只有一個副本)。至於什麼是HAT,論文第5節專門描述它:HAT systems provide transactions with transactional availability or sticky transactional availability。並且列出了HAT可以做到和不能做到的語義。

HAT可以做到:

  1. 原子性(不管涉及到多少個節點)
  2. RC和RR
  3. 會話層級的read-your-writes,monotonic reads (i.e., time doesn’t go backwards), and causality within and across transactions
  4. Eventual consistency, meaning that, if writes to a data item stop, all transaction reads will eventually return the last written value

HAT做不到:

  1. 分區後的資料recency
  2. HATs cannot be “100% ACID compliant” as they cannot guarantee serializability, yet they meet the default and sometimes maximum guarantees of many “ACID” databases.
  3. HATs cannot guarantee global integrity constraints (e.g., uniqueness constraints across data items) but can perform local checking of predicates (e.g., per-record integrity maintenance like null value checks).
3 列出所有的現象/異常
  1. 傳統資料庫隔離等級相關的現象/異常。
    • P0, Dirty Write
    • P1, Dirty Read
    • P2, Non-repeatable Read, Fuzzy Read
    • P3, Phantom,注意包括插入、刪除和更新三種情況
    • P4, Lost Update
    • A5 (Data Item Constraint Violation)
      • A5A Read Skew
      • A5B Write Skew
    • A Critique中有,但是這裡沒有單獨列出來的:P4C,A1,A2,A3。
    • MAV,讀到事務的原子的修改
    • RA,Read Atomic isolation,類似Oracle的TSC
  2. 會話相關的現象/異常。
    • Read Your Writes
    • Monotonic Writes
    • Monotonic Reads
    • Writes Follow Reads
    • Pipelined Random Access Memory (是上面前三者的組合)
    • Causal consistency(是上面前四者的組合,也就是PRAM和Writes Follow Reads的組合)
  3. 分布式系統一致性相關的現象/異常。
    • Recency(這個似乎是多出來的,應該不算)
    • Safe Register
    • Regular Register
    • Linearizability
  4. 可序列化
    • 傳統的可序列化定義的是單副本的情境。
    • 在多副本的情境下,定義One-copy可序列化。
    • 它與Linearizability一起構成了嚴格可序列化。


Footnotes:1 

http://iggyfernandez.wordpress.com/2010/09/20/dba-101-what-does-serializable-really-mean/

http://research.microsoft.com/pubs/69541/tr-95-51.pdf

http://www.bailis.org/blog/hat-not-cap-introducing-highly-available-transactions/

http://www.bailis.org/blog/when-is-acid-acid-rarely/

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.