關係型資料庫成功分片的3個關鍵原則

作者｜Ozgun Erdogan編輯｜薛命燈

來自 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 類型的應用最容易進行分片。

華為吳晟：分散式監控系統的設計與實現

CNUTCon 全球運維技術大會將於 9 月 10-11 日在上海舉行，大會以「智能時代的新運維」為主題，涵蓋 AIOps、SRE、DevOps、運維監控與安全等專場，邀請了來自 Google、Uber、eBay、BAT 等公司大咖分享他們在最新運維技術實踐過程中遇到的坑與經驗，現場為你解疑答惑，點擊「閱讀原文」了解更多精彩！9 折限時優惠，報名時輸入 CNUTCon666 還可再減 200 哦！