📑
scrapbook
  • Introduction
  • 1. Concept
  • 1.1 EAI
  • 1.2 ESB
  • 1.3 EAI v.s. ESB
  • 1.4 SOA
  • 1.5 RESTful
  • 1.6 Microservices
  • 1.7 Microservice v.s. SOA
  • 1.8 Maintain HTTP State
  • 1.8.1 Cookie
  • 1.8.2 Session
  • 1.9 Put, Add, and Set
  • 1.10 Public Key & Private Key
  • 1.11 Message Digest & Hash Function
  • 1.12 Diffie - Hellman Key Exchange
  • 1.13 About IoC
  • 1.14 About AOP
  • 1.15 Spring - Pros and Cons
  • 1.16 Spring - Prototype in Singleton
  • 1.17 HTTP v.s. SPDY
  • 1.18 HTTP/2
  • 1.19 Securing REST Services
  • 1.20 Conway's Law
  • 1.21 大型網站架構演化發展歷程
  • 1.22 Java Generics
  • 1.23 MySQL HA經驗談
  • 2. Questions & Solutions
  • 2.1 海底撈幾根針
  • 2.2 塞不進去
  • 3. Relational Database
  • 3.1 SQL Join Type
  • 3.2 SQL Injection
  • 3.3 MySQL CHAR v.s. VARCHAR
  • 4. NoSQL
  • 4.1 CAP Theorem, ACID v.s. BASE
  • 4.2 Two-Phase-Commit
  • 4.3 RDB v.s. NoSQL
  • 4.4 Structured, Unstructured and Semi-structured Data
  • 4.5 Shard v.s. Replica
  • 4.6 ArrayList v.s. LinkedList
  • 4.7 HashSet v.s. TreeSet
  • 4.8 HashMap v.s. TreeMap
  • 4.9 ArrayList v.s. Vector
  • 4.10 HashMap v.s. HashTable
  • 4.11 Statement, PreparedStatement and CallableStatement
  • 4.12 Overflow of Digits
  • X. JVM
  • X.1 JVM System Threads
  • X.2 Garbage Collection
Powered by GitBook
On this page
  • CAP Theorem
  • ACID (For Relational Database)
  • BASE (For Non-Relational Database)

Was this helpful?

4.1 CAP Theorem, ACID v.s. BASE

Previous4. NoSQLNext4.2 Two-Phase-Commit

Last updated 5 years ago

Was this helpful?

這邊我想寫一些RDB跟NoSQL的比較, 所以會先提到一些基本觀念:

CAP Theorem

對於一個分布式計算系統來說, 不可能同時滿足以下三點:

  • Consistency: 系統在執行過某項操作後仍然處於一致的狀態, 在分布式系統中, 更新操作執行成功後所有的用戶都應該讀取到最新的值, 這樣的系統被認為具有強一致性

  • Availability: 每一個操作總是能夠在一定的時間內返回結果, 或可想成任何時間點都可讀寫(可用性), 即任何一個節點失效都不會影響其它節點繼續運作

  • Partition tolerance: 系統若處於網路分區的情況下仍然可以接受請求並處理, 此處的網路分區是指由於某些原因導致網路被分成了若干個孤立區域, 且區域之間不互通. 當然, 這其實也相當於對通信的時限要求, 因為系統若不能在時限內達成資料一致性, 就意味著發生了分區的情況

為什麼不能同時滿足三點? 簡單來說:

  • 要讓資料有高可用性(availability), 就得寫多份資料

  • 寫多份資料就會出現資料一致性的問題(consistency)

  • 而資料一致性的問題又會延伸出性能的問題(partition tolerance)

而根據Ryan Barrett的演講""中提到的一張圖, 該圖如下:

你可以發現, 我們基本上來說不可能讓所有的項目都變綠色, 這就是CAP Theorem.

所以, 我們可以根據CAP來把DB分成以下三種類型:

  • CA: 單點集群, 滿足了一致性和可用性, 通常在可擴展性上不太強大, 如relational database, 若只有一台機器的話是不能實現CA的

  • CP: 滿足一致性和分區容錯性, 通常性能不是特別高, 如分布式資料庫

  • AP: 滿足可用性即分區容錯性, 通常對一致性的要求就沒那麼高, 如大多數的NoSQL

ACID (For Relational Database)

  • Atomicity: 原子性, 即transaction中的所有操作, 要就全都成功, 不然就全都失敗

  • Consistency: 一致性, 在transaction的開始與結束時, DB都處於一致的合法狀態, 例如從A的帳戶轉1000塊錢到B的帳戶, 則在這個交易的開始與結束, 總金額是一樣的. 此處的consistency跟CAP theorem裡的consistency是不同的東西, 別搞混了

  • Isolation: 隔離性, 同時進行的transaction間, 互相不影響

  • Durability: 在transaction結束時, 此操作是不可逆的, 即commit之後, 系統將保證資料不會丟失, 即便是系統crash

題外話, 其實大多數的DB廠商都體會到了DB分區的必要性, 所以引入了一種稱為2PC(Two-Phase-Commit)的技術來提供跨越多個DB instance的ACID保證, 這個部分會在後面章節提到.

BASE (For Non-Relational Database)

  • Basically Available: 系統能夠基本運行, 一直提供服務

  • Soft-state: 系統不要求一直保持強一致狀態

  • Eventual consistency: 系統需要在某一時刻後達到一致性要求

BASE模型可視為傳統ACID模型的反面, 由上可知, 不同於ACID, BASE強調犧牲consistency, 從而得到availability, 資訊允許在一段時間內的不一致, 只要保證最終一致即可.

Transaction Across DataCenter