初步認識分散式資料庫與 NoSQL CAP 理論

(以下圖片來源出自讀書會成員講義)

在談分散式以前,首先來談談單機運作的概念。當我們的服務是單機運作時,伺服器的架構設計通常會是以下其中一種:

  • 一個服務在一台電腦運行
  • 多個服務在一台電腦運行

這種狀況下若是要擴展系統容量,只能升級電腦資源獲提升程式效率,這種方式也被稱為「垂直擴展(Vertical Scaling)」。

不過這樣的架構又衍生出兩個問題:

  1. 單機能力的提升是有極限的
  2. 單點故障的風險(Single Point of Failure): 若只依靠單機運行,假設今天資料庫的主機掛了,你的服務也就 GG 了。換句話說就是缺少容錯能力,無法在維持服務的前提下升級。

為了解決以上的問題,有個解法誕生了:

嘗試開很多個機器跑同一個服務,也就是採用分散式架構

在開了很多台機器後,我們似乎得到以下的好處:

  • 來自 client 的請求可以分配到這幾台主機之一,減緩單一主機的壓力。
  • 因為第一點,某種程度降低了服務的等待時間。
  • 提高了系統的容錯能力,即是一個分區容錯(Partition Tolerence)的系統,當節點間通訊失敗也不會影響系統正常運作。
  • 採用分散式架構後,甚至可以在不同地理區域就近服務使用者。

這種增加節點的擴容方式,被稱作水平擴展(Horizontal Scaling)

然而,事情不像外表看起來那麼單純又美好,進入分散式世界後所需要考慮的事情變得更多更複雜了。

在上一篇文章中我們提及 transaction 可以解決資料一致性的問題,然而在分散式架構下我們無法僅靠 transaction 就確保一致性,必須額外搭配共識(Consensus)的機制。

接下來介紹幾個名詞:

  • Consistency 一致性 : 保證在各個有儲存資料的分區都一定拿得到最新版本的資料。
  • Availability 可用性:當存取資料庫時一定可以拿到資料,不會出錯(不會出現拿不到資料的狀況,但拿到的資料不保證是最新版本。)
  • Partitioning Tolerance 分區容忍:文章前段有提及,即使任一節點發生錯誤,整個系統還是能正常運作。

問題來了,有辦法同時達到 C (一致性),、A (可用性)、P (分區容忍) 嗎?

答案是沒辦法。讓我們來看看 CAP 理論是什麼。

CAP 理論

圖片來源

所謂 CAP 理論以中文有名的諺語來說就是「魚與熊掌不可兼得」在分散式系統中不可能同時滿足 CAP 三者。CAP (C (一致性),、A (可用性)、P (分區容忍))三者只能擇其二(或是勉強都達到一點點點),也就是選擇了 P,就只能再從 C, A 中二選一,如果 CA 都要拿,那就都會無法做到完美。

幾種 CAP 的組合

AP Database — 犧牲一致性的分散式資料庫

在分區容忍的前提下(因為都已經採用分散式架構了),犧牲一致性來提高可用性(盡可能每次都得到回應),不過雖然犧牲了一致性,卻仍可以達到最終一致性(Eventual Consistency,例如總統大選開票時每家新聞台的即時票數都不一致,但在選舉結束後的票數還是會達成一致。),適合在需要快速讀寫,但資料對於一致性的需求較低的場景,例如臉書或各大媒體平台的按讚系統。

例如:Amazon DynamoDB

CP Database — 犧牲可用性的分散式資料庫

在分區容忍的前提下,依然可以得到最新版本的資料,常用於貼文系統、訊息系統等不能犧牲一致性的系統。

例如:Google BigTable、MongoDB、分散式的 RDBMS

CA Database — 犧牲分區容忍性的資料庫

這樣就違反了分散式架構的初衷,因此基本上不會存在於分散式系統中。

例如:單機或是經過 Sharding 的資料庫(不能承受單機損壞)。

Scaling & Availability

接著來提一下擴展與可用性。

Q: RDBMS 怎麼做 Scaling ?

A: Database Sharding。

不過實作過程可說是非常複雜。

Q: 那 RDBMS 怎麼做到高可用性呢?(HA, high availability)

A:

看完 RDBMS,換來看看 NoSQL 的優缺點。

NoSQL 解決了什麼問題?

  • 容易擴展的設計架構,由於資料沒有關聯性,因此相較於 RDBMS 更易於 scaling。
  • 簡單快速的達到高可用性(HA): Hash Function: O(1), Distributed Hash Funciton: O(log n)
  • 容易進行 Schema 的變更,因為根本沒有 Schema,適合時常變更架構的系統。

然而,老樣子,沒有絕對完美的事情,NoSQL 一樣存在缺點。

NoSQL 的缺點

  • 沒有固定的 Schema : 這點其實嚴格來說可以是優點也可以是缺點,得看需求來定論。
  • 關聯式資料庫常見的 Transaction 與 JOIN 也就非常難在 NoSQL 實踐。
  • 資料量不夠大時,其實效能普遍比 RDBMS 來要差

這邊提到了 Transaction,剛好在之前的篇章也淺淺介紹過 transaction,不過當時只考慮到單機運行的狀況,那在分散式的架構下的 Transaction 又會有什麼不一樣呢?文章開頭有提到,我們需要共識機制的幫忙。

其實共識機制有非常非常多種,不過在分散式資料庫中最常見的共識機制就是 2PC 這個共識機制。

分散式關聯性資料庫的範例:

關於分散式交易的更多資訊

小結

透過這篇文章,我們大概了解了單機與分散式的架構差異,還有一致性、可用性、分區容忍性魚與熊掌不可兼得的 CAP 理論,也理解到不同組合的資料庫種類,還有分散式架構需要共識機制來完成交易,最後也稍微提到 RDBMS 與 NoSQL 非別怎麼擴展與兩者的區別。不過這篇真的是超淺淺淺談,現實面還有很多需要考慮的問題,分散式也未必是大流量需求下最佳的選擇,因此想要使用時還要謹慎看待囉!

--

--

--

什麼都想學的雜食性軟體工程師 🇹🇼 (https://github.com/kylemocode) 合作與聯繫 📪 oldmo860617@gmail.com

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
莫力全 Kyle Mo

莫力全 Kyle Mo

什麼都想學的雜食性軟體工程師 🇹🇼 (https://github.com/kylemocode) 合作與聯繫 📪 oldmo860617@gmail.com

More from Medium

Partitioning Project Variations in Git Branches

SOLID: What is? Why this? How use?