上篇介紹了 RDBMS 的擴展方式: replica, sharding, consensus
由於這些擴展方式也都適用於 NoSQL Database
並且相較於 RDBMS 需要自己實作擴展, NoSQL Database 通常已經實作好, 只要寫設定檔即可

此外, 這篇提到的擴展方式理論上也適用於 RDBMS, 只是由於需要自己實作
並且因為 ACID 特性的關係會很難處理, 所以不歸類在前篇內容

Sharding

就像前篇提到的 訂房系統 的範例, 我們可以根據某個欄位 sharding, 將資料分散到不同伺服器
NoSQL Database 如 Cassandra 則使用如 Consistent Hashing 來分散資料

Consistent Hashing

Consistent Hashing 讓 NoSQL Database 節點可以動態調整節點的數量, 同時保持資料分散儲存
這邊簡單介紹如何運作

1. 根據 節點 的獨特值如 IP, 名稱等計算出 Hash 值
2. 當所有節點都有 Hash 值後, 即形成 Hash Ring
3. 當資料進來時, 根據設定的 Hash Key 計算該資料的 Hash 值
4. 根據 資料 和 節點的 Hash 值, 找出順時針下距離最近的 節點
5. 儲存到該節點

問題是誰要負責處理第 3, 4 步呢?

Routing

各家 NoSQL Database 用不同的元件負責分配, 但主要有以下幾種

1. 客戶端
2. Coordinator 節點
3. Distributed Hash Table (DHT)

客戶端

透過客戶端自行計算資料的 Hash 值並決定要存到哪個 Database 節點

好處是沒有中心化的節點, 避免了效能瓶頸和 SPOF
缺點是客戶端需要知道實作細節

如 Cassandra, Riak

Coordinator 節點

由一個中心化的節點負責

好處是將請求的邏輯放在後端自行維護
缺點是容易有效能瓶頸和 SPOF

如 MongoDB 的 mongos

DHT

(題外話: 用過 BitTorrent 應該不陌生XD)

DHT 主要用在 去中心化 的分散式系統
相較於第一種客戶端僅負責計算 Hash 值和決定儲存的節點
DHT 中的 "所有節點" 都能夠儲存一部份的資料
也能夠讓其他節點取得這些資料
(題外話 2: 如同上篇提到的 共識演算法, 所有節點的責任相同)

好處是避免了中心化節點有的效能瓶頸 和 SPOF
缺點是要求每個節點都有足夠的資源計算並處理請求

如 Riak (Note: 沒查到官方文件, 從一些論壇看到的@@)

Reference

• A Guide to Consistent Hashing: How it Works and Why it's Effective
• Riak - web-shaped data storage system
• Consistent hashing algorithm