关系型数据库的分片原则
來自Citus的Ozgun Erdogan分享了進行數據庫分片的三個原則，并強調應用類型是決定數據庫分片最主要的因素。其中B2B類型的應用最容易進行數據庫分片。
在數據庫很小的時候，可以很容易地通過添加硬件來擴展數據庫。但隨著數據表數量的不斷增長，我們需要尋找其他的方式來伸縮數據庫。
分片是伸縮數據庫最好的方式之一。通過分片將數據庫拆分成更小的單元，可以線性地擴展數據庫的CPU、內存和磁盤資源。不過在分片這個問題上也存在一些爭議，網絡上充斥著各種有關分片的不同觀點，如“essential to scaling your database infrastructure”和“why you never want to shard”。那么問題來了，我們應該采納哪一種觀點？而一般來說，答案通常會是“它取決于”。
分片的原理很簡單，就是通過一個鍵（或者說列）來均勻地分布數據。不過理論雖簡單，在真正遇到要對數據庫進行分片時，很可能會陷入一團手忙腳亂之中。
在Citus，我們曾經幫助數百個團隊進行數據庫分片，也從中總結了一些關鍵的分片模式。
在這篇文章里，我們會先探討一些決定分片成敗的關鍵屬性，然后從底層細節分析這些屬性之間的不同點。在進行大型數據庫分片時，應用程序的類型將成為最主要的影響因素。
成功分片取決于三個關鍵屬性
我們發現有三個關鍵屬性會影響到成功的分片。下圖通過三個方向軸展示了這三個屬性，并在每個軸上面放置了一些知名的公司作為例子。
X-軸表示負載類型，從左側的事務開始延伸到右側的數據倉庫。在進行數據庫伸縮時，這一維度最具有識別度。
Z-軸表示另一個非常重要的屬性，也就是應用程序當前所處的生命周期。此時你的數據庫里有多少數據表？你的應用程序已經運行了多長時間？一個運行了幾個月的數據庫要比運行了數年的數據庫更容易進行分片。
在Citus，我們發現大部分用戶都有自己的應用程序。應用程序越是成熟，Y-軸就顯得越為重要。不過這個維度不如其他兩個維度那么具有識別度。事實上，很多討論分片的文章之所以會得出互相矛盾的結論，是因為它們只是基于單一的應用類型。
分片中最重要的屬性：應用類型（B2B或B2C）
Y-軸展示了在對成熟數據庫進行分片時最為重要的屬性：應用程序的類型。在這條軸上，B2B應用處于最上端，它們的數據模型更容易進行分片。B2C應用處于軸的底部，比如Amazon和Facebook，它們的分片需要做更多的工作。接下來，我們挑選了三家知名的公司來比對它們之間的不同點。
B2B類型：Salesforce
CRM系統是B2B應用最為典型的例子。構建CRM系統的目的是為了要給其他客戶提供服務的，我們假設GE Aviation是你的一個客戶，他們正在使用Salesforce。
GE Aviation有如下的一些實體。
客戶（customer）：公司的顧客。
用戶（user）：用戶可以登錄GE公司的儀表盤。
負責人（lead）：GE與這些負責人商談業務。
聯系人（contact）：GE與這些聯系人有了業務往來，并知道他們的聯系方式。
賬號（account）：業務代表和擁有聯系人的人。
機會（opportunity）：與賬號和聯系人相關的銷售事件。
如果把這些實體之間的復雜關系映射到數據庫里，看起來是這樣的：
整個圖咋一看確實很復雜，不過如果你多花一點時間看仔細一點，你會發現大多數表都是源自customer表。通過往每個表里添加customer_id列可以把表間關系轉換成如下形式：
通過這種簡單的轉換，就可以通過customer_id這個鍵進行數據庫分片。這個鍵可以讓數據均勻地分布，而大部分查詢都需要帶上這個鍵。另外，你還可以根據customer_id把相關表聚集在同一個位置，這樣就可以繼續使用關系型數據庫的一些關鍵特性，比如事務、表連接和外鍵。
換句話說，如果你的應用類型是B2B的，那么你的數據就具備了分片的天然特性。
B2C類型：Amazon
Amazon是B2C應用最為典型的例子。在構建像Amazon這樣的網站時，有許多東西需要考慮。首先，用戶來到你的網站，瀏覽你的商品，比如書或電子產品。假設用戶在瀏覽《Harry Potter 7》，他們也可以看到這個產品的分類信息，比如書本的作者、價格、封面和其他圖片。
用戶在登錄網站之后，開始訪問用戶相關的數據。用戶需要得到認證，然后獲得給產品添加評論的權限或者把產品添加到購物車里。在某個時候，用戶決定要購買購物車里的產品，于是就下單。訂單經過處理之后，開始進入物流運送流程。
你會發現，現在的關系圖與Salesforce的關系圖有一個很大的不同點。現在的關系圖中不止一個中心點，而是三個：分類（catalog）、用戶（user）和訂單（order）。
要對這種B2C類型的數據進行分片，可以考慮將它們重構成微服務。例如，與產品目錄相關的服務提供目錄服務，用戶相關的服務提供認證和購物車服務。服務之間的API定義了底層數據訪問的邊界。
數據經過拆分之后，就可以進行分片。事實上，Amazon在遷移到面向服務架構時就使用了類似的方式進行數據分片。
這種分片方式與B2B應用的分片在好處和成本比率上有很大的差別。從好處方面來看，你可以依賴數據庫從不同的數據庫連接數據，或者為數據集提供事務和約束。從成本方面來看，現在要進行分片的不止是一個數據集，而是多個。
B2C2C類型：Instacart
在B2B和B2C之間還有另外一種類型的網站，比如Postmates、Instacart或Lyft。[Instacart][12]的主營業務是將本地商店的貨物運送給用戶。從某方面來看，Instacart與Amazon有點類似。Instacart的數據模型具有三個維度：提供貨物的本地商店、訂購商品的用戶和運送貨物的司機。所以，很難在這當中挑出一個鍵進行分片。
如果你的應用屬于B2C2C類型，可能需要采取不同的策略。你會發現大部分數據表會共享一個維度：地理位置信息。在這種情況下，你可能會選擇城市或地理位置作為分片的鍵。
一般來說，B2B2C應用或B2C2C應用的分片處于圖譜的中間。B2B2C分片的好處和成本之間的比率要高于B2C應用，但低于B2B應用。
結論
網絡上存在很多有關分片的觀點。我們發現它們大部分都是基于單一的應用類型。事實上，應用類型比其他因素更能影響到分片。B2B類型的應用最容易進行分片。
原文地址：http://www.infoq.com/cn/news/2017/08/fragmentation-principle-relation
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的关系型数据库的分片原则的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .Net Core下通过Proxy 模式
- 下一篇： MySql 使用 EF Core 2.0