資料庫sharding的基本思想和切分策略

2022-08-30 10:42:13 字數 1487 閱讀 4716

一:基本思想

sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫(server)上,從而緩解單一資料庫的效能問題。不太嚴格的講,對於海量資料的資料庫,如果是因為表多而資料多,這時候適合使用垂直切分,即把關係緊密(比如同一模組)的表切分出來放在乙個server上。如果表並不多,但每張表的資料非常多,這時候適合水平切分,即把表的資料按某種規則(比如按id雜湊)切分到多個資料庫(server)上。當然,現實中更多是這兩種情況混雜在一起,這時候需要根據實際情況做出選擇,也可能會綜合使用垂直與水平切分,從而將原有資料庫切分成類似矩陣一樣可以無限擴充的資料庫(server)陣列。下面分別詳細地介紹一下垂直切分和水平切分.

垂直切分的最大特點就是規則簡單,實施也更為方便,尤其適合各業務之間的耦合度非常低,相互影響很小,業務邏輯非常清晰的系統。在這種系統中,可以很容易做到將不同業務模組所使用的表分拆到不同的資料庫中。根據不同的表來進行拆分,對應用程式的影響也更小,拆分規則也會比較簡單清晰。(這也就是所謂的」share nothing」)。

讓我們從普遍的情況來考慮資料的切分:一方面,乙個庫的所有表通常不可能由某一張表全部串聯起來,這句話暗含的意思是,水平切分幾乎都是針對一小搓一小搓(實際上就是垂直切分出來的塊)關係緊密的表進行的,而不可能是針對所有表進行的。另一方面,一些負載非常高的系統,即使僅僅只是單個表都無法通過單台資料庫主機來承擔其負載,這意味著單單是垂直切分也不能完全解決問明。因此多數系統會將垂直切分和水平切分聯合使用,先對系統做垂直切分,再針對每一小搓表的情況選擇性地做水平切分。從而將整個資料庫切分成乙個分布式矩陣。

二、切分策略

如前面所提到的,切分是按先垂直切分再水平切分的步驟進行的。垂直切分的結果正好為水平切分做好了鋪墊。垂直切分的思路就是分析表間的聚合關係,把關係緊密的表放在一起。多數情況下可能是同乙個模組,或者是同一「聚集」。這裡的「聚集」正是領域驅動設計裡所說的聚集。在垂直切分出的表聚集內,找出「根元素」(這裡的「根元素」就是領域驅動設計裡的「聚合根」),按「根元素」進行水平切分,也就是從「根元素」開始,把所有和它直接與間接關聯的資料放入乙個shard裡。這樣出現跨shard關聯的可能性就非常的小。應用程式就不必打斷既有的表間關聯。比如:對於社交**,幾乎所有資料最終都會關聯到某個使用者上,基於使用者進行切分就是最好的選擇。再比如論壇系統,使用者和論壇兩個模組應該在垂直切分時被分在了兩個shard裡,對於論壇模組來說,forum顯然是聚合根,因此按forum進行水平切分,把forum裡所有的帖子和回帖都隨forum放在乙個shard裡是很自然的。

對於共享資料資料,如果是唯讀的字典表,每個shard裡維護乙份應該是乙個不錯的選擇,這樣不必打斷關聯關係。如果是一般資料間的跨節點的關聯,就必須打斷。

兩個或多個shard放到同乙個資料來源裡,每個shard依然是獨立的,它們有各自的主表,並使用各自主表id進行雜湊,不同的只是它們的雜湊取模(即節點數量)必需是一致的。(

本文著重介紹sharding的基本思想和理論上的切分策略,關於更加細緻的實施策略和參考事例請參考我的另一篇博文:資料庫分庫分表(sharding)系列(一) 拆分實施策略和示例演示 

資料庫Sharding的基本思想和切分策略

一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上,從而緩解單一資料庫的效能問題。不太嚴格的講,對於海量資料的資料庫,如果是因為表多而資料多,這時候適合使用垂直切分,即把關係緊密 比如同一模組 的表切分出來放在乙個server上。如果表並不多,但...

資料庫Sharding的基本思想和切分策略

本文著重介紹sharding的基本思想和理論上的切分策略,關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上,從而緩解單一資...

資料庫Sharding的基本思想和切分策略

本文著重介紹sharding的基本思想和理論上的切分策略,關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上,從而緩解單一資...