五種資料庫資料模型分片策略

banq發表於2017-08-29
資料庫模型
擴充套件資料庫會遭遇挑戰，本文提供了五種資料庫分片Sharding策略供參考。

當然，除了分片策略以外，最簡單辦法是擴充套件硬體，另外是刪除可能不需要的資料，或嘗試使用微服務解決。

下面著重談談五種分片策略：


一、根據客戶或租戶進行切片

SaaS應用程式通常為許多客戶（稱為“租戶”）服務，這就是為什麼我們經常將這些應用程式稱為“ 多租戶應用程式”。如果您是SaaS業務，客戶們的資料通常不會相互影響。而社交網路應用則與此不同，社交網路應用中不同使用者生成的資料之間存在很多相互依存關係。

使用多租戶的SaaS應用程式，資料通常應該是事務性的。如果您丟失了一些資料，付費客戶會抗議投訴。由於許多這些事務型多租戶SaaS應用程式（比如：CRM軟體，營銷操作，網路分析）的性質，當資料儲存到資料庫時，您需要強有力的保證資料能確實儲存下來了。客戶希望您執行引用完整性。

多租戶應用程式另一個有趣的事情是，他們的資料模型隨著時間的推移而發展，提供越來越多的功能。不同於C2C是受益於網路效應而擴充套件規模，B2B應用程式是透過為客戶新增新的（粘性）功能而不斷增長擴充套件。新功能意味著新的資料模型。最終的結果是從10個表到100個表，有時是複雜的join。如果這聽起來和你一樣，按租戶分割是一種安全（推薦）的分片方法。


二、按地理劃分

近年來興起一種基於地理位置的應用程式，這些應用程式關鍵是地理位置：感謝iPhone。無論是Lyft，Instacart還是Postmate，這些應用程式都與位置有重要的聯絡。

但是，只是因為你有一個注重地理的應用程式，這並不意味著地理是正確的分片key。按區域劃分的關鍵是您的特定地理位置中的資料不與另一個地理位置進行互動。並不是所有具有地理資料的應用程式進行地理分片是有道理的。

與上述多租戶應用程式類似，依賴於地理位置的應用程式的資料模型往往更加演變。隨著應用程式依賴於位置，你有一些表之間存在外來鍵依賴關係，並經常在他們的查詢之間相互聯絡。如果您能夠將查詢限制在單個地理位置，並且資料很少跨越地理邊界，則按地理劃分可能是一個很好的方法。

三、按實體ID分片（隨機分佈資料）

這種模型切分方法可以適用於許多不同的資料庫系統，這種方法的前提條件是資料模型之間沒有強大的相互依賴關係，也就是沒有Join，也沒有因Join發生事務機制的需要，在這樣前提下，如果你面臨有一個單節點（或核心節點）的資料庫中資料太多，導致無法快速處理，就可以使用本策略。

當透過實體id分片時，我們希望儘可能均勻地分佈資料，以最大限度地提高系統中的並行性。為了能完全均勻分佈，需要透過隨機ID進行分片，採用類似負載平衡策略round-robin方式輪詢資料。

如果您的查詢根本沒有Join，那麼使用一個uuid來分割資料可能會很有意義。如果您有幾個與會話相關的join，則可以使用相同的分片key來分割相關表(根據會話分片)。


四、根據graph分片

現在我們來看看最獨特的方法。在檢視圖graph資料模型時，w為了分析方便，會看到不同的擴充套件方法和不同的意見。圖模型在流行的B2C應用程式（如Facebook和Instagram）中是最常見的，這些應用程式會使用圖資料庫graph database。

使用圖資料庫，有兩個關鍵點，物件代表有型別的節點，而關聯代表它們之間的連線。比如張三訂閱關注了李四，物件就是李四經常發生的更新，關聯就是誰訂閱了這些更新。

使用此模型，資料通常以幾種不同的形式進行復制（主從複製）。那麼應用程式的責任是對映到最有用的能獲取資料的資料表表。這樣就有多種以不同方式切分過的資料副本，它們是最終實現資料的一致性，然後必須將一些應用程式邏輯對映到分片策略，對於像Facebook和Reddit這樣的應用，除了採取這種方法之外別無選擇，但它確實有一定的代價。

五、時間劃分

分片的最終方法是順應某些應用程式自然而然的傾向。如果您正在處理時間為主軸的資料，則按日，周，小時，月份分割槽是正確的。檢視某種形式的事件資料時，時間分割是非常常見的。事件資料可能包括廣告的點選次數/展示次數，可能是網路事件資料，或者來自系統監控的資料。

下面情況您將需要使用基於時間的方法進行分割槽：

（1）透過對資料進行分析，以時間為橫軸，生成報告/警報。
（2）你會經常來回翻閱歷史資料，因此在時間上你需要保留一定歷史資料。

時間分割槽上有意義的一個例子是，當您是僅輸出30天廣告資料時或者：您正在監控網路日誌，但是僅需要檢視最近7天。如果一年前的時間裡混合了最近的資料（最近7天）和歷史資料時，實現這些功能就會出現了困難。

分片的正確方法取決於您的應用程式

與許多關於架構和基礎設施的決策一樣，必須適時做出折衷，最好方法是將分片策略與您的應用程式的需求（以及您的客戶的需求）相匹配。在分片的情況下，將分片型別與您的應用程式是能夠實現有效擴充套件的關鍵。當您將資料模型和用例與正確型別的分片相匹配時，許多重要的問題：如重新投入重寫應用程式、如何確保資料一致性、在6個月後更新時遇到問題等可能會自然消失。


Five sharding data models and which is right

相關文章