筆者不只是SCYLLA小白，其實也算是半個分散式系統的小白。

想到當初原來是太欠缺分散式系統的基本概念，接觸mongoDB時磕磕碰碰地一路辛苦，所以文章裡面多少也簡介一些分散式系統的概念。

並不是SCYLLA的學習門檻太高，是如果以前都沒碰過分散式結構的前提，會變成一次要學兩種東西，分散式系統+分散式的NoSQL DB。

回歸正題，別於關聯式DB在機器上的系統結構(單台/主從)，CASSANDRA/SCYLLA就是一種多台的分散式的架構，分散式的DB。

關聯式DB一定有個主(master)節點，分散式的架構去中心化，並沒有master-slave的概念。

關聯式DB的master節點，往往也是效能瓶頸的所在，因為slave可以多台，關鍵的master只能有一台，寫入的操作都是往master擠。

雖然說這可能是關聯式DB的瓶頸，相對的，這也是關聯式DB巨大的優勢，它保證了資料的一致性，基本上有寫到master的資料，不用擔心slave拿到的資料會不一樣，當然同步落後問題，不在此列。

分散式DB就沒有辦法很輕鬆的達到資料寫入可靠性保證，因為架構的關係，在短暫的同一個時間點，有可能在不同節點上的資料會有所出入，尤其每次寫到的機器，不一定是在同一台，這就牽扯資料一致性的問題。

一致性嚴格來說又可以分成幾種，順序(強)一致性，因果一致性，對於CASSANDRA/SCYLLA，策略上是追求資料最終(弱)一致性，

說到這裡，對於分散式系統概念，我們要提一下CAP定理。

CAP

以下引用wiki上的解釋，以及筆者找到一些更直白的敘述，希望幫助大家更明白這3個原則在講什麼：

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對於一個分布式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistency） （等同於所有節點訪問同一份最新的數據副本）

所有資料庫客戶端同時更新，用同樣的查詢，一定取得相同的值。

• 可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據）

總是可以讀寫，不會因為資料失效，而遇到無法讀取之類的狀況。

• 分區容錯性（Partition tolerance）（以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。）

數個節點之間的網路或溝通出現問題，還是可以對外提供服務。

根據定理，分布式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想像兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了C性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那麼又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質。

CAP 指的是分散式系統就會有這樣的特性，並非特定發生在NoSQL的分散式DB身上。

由上面定理可知，CASSANDRA/SCYLLA這種分散式的DB，一定要在3原則當中，選擇犧牲某些東西，於是定位在追求最終一致性，而換取其他方面的優秀表現。

與之相比，關聯式DB，大家會容易討論到的就是ACID特性，關聯式DB架構設計的關係，可以很好地達成ACID。

要注意一點，並不是指CAP和ACID是相同層次的討論議題。

關聯式DB跟CAP絕對無關，因為這是分散式架構的議題，關聯式DB也做不到分散式架構。

分散式架構，卻可以追求ACID，但是稍微了解分散式架構的概念，要做ACID(簡單來說，可以理解為想做交易機制)，就大概可以想像有多麽困難，光是節點與節點的溝通上面就會讓你頭痛萬分。

常見的解法或策略，可能聽說過2PC的做法，或者補償機制之類的，但是成本額貴且很有局限性，以及要額外考量的衍生問題也會很多。

說明這麼多理論的層面的東西，是由衷希望能夠幫助大家，在挑選什麼樣的DB作為最佳的應用場景，適用性最好，有個決策的依據與判斷。

工具用得不對，不能怪工具爛嘛。

高可擴充性的分散式系統

服務設備的擴充，簡單分兩種方式，垂直擴充和水平擴充。

垂直擴充指的是單點機器設備的性能提升，今天機器不夠力，換一台更好更貴的機器上去，那麼服務的量能就明顯提升上去了，但是短時間內，或者遇到緊急狀況時，這樣的做法，絕對不是那麼容易。

水平擴充，指的是增加服務機器的數量，在現代虛擬化、容器化、上雲端盛行的時代，這樣的擴充是分秒就能完成的事情，而且可以作到自動化，達到服務不中斷的優勢。

光是水平擴充容易這項優點，就值得思慮應用的場景了，無關今天用的DB是SCYLLA還是CASSANDRA，甚至用Mongo DB，都是一樣的，因為這是分散式的架構。

在此我們就可以知道，如果你的服務量級一直在擴張，對於擔心DB容量不夠，速度隨著時間漸漸變慢，或者本身服務的處理資料量就非常巨大，寫入的需求壓不下來，系統的瓶頸卡在DB的處理上，那麼也許就這點來說，就可以考慮用NoSQL來實作。

重要資料的處理

有些關鍵的資料，除了萬分要求可靠的一致性以外，處理速度上也有所要求。

如金錢、庫存、成立訂單部分，遇到這類需要做交易機制的處理，在分散式系統硬要做，又要做得好，除了成本代價高，也很容易衍生問題。

雖然分散式系統好擴充，但要做交易機制處理的部分，暴露的風險非常嚴重，這些部分的處置，基本上一點都不能錯，試想比方說，銀行系統若不小心把你的錢弄丟了，你會做何感想？

於是重要的資料，仍然建議使用關聯式DB，寧願系統慢，也不要有出差錯的可能。

所以筆者的工作環境，關聯式DB和SCYLLA是併行使用著，就是這麼簡單的道理。