關聯式資料庫分片原則

banq發表於2017-08-12
原文網址 : https://www.jdon.com/49022
資料庫
本文主要討論了兩種資料庫分片方式，基於業務的自然分表法和基於微服務的分片法。其實微服務的切分依據還是要首先找出業務資料的DDD聚合才能切分。

當資料庫資料量很小時，很多問題可以透過硬體進行擴充套件。然而，隨著資料表數量的增長，就需要考慮其他擴充套件資料庫的方法了。

在某種程度上，分片Sharding是最好的擴充套件方式。分片讓你將資料庫切分成較小的部分，以實現資料庫cpu、記憶體和磁碟資源的線性擴充套件。但是，分片是一個有爭議性的話題。網際網路上有關於分片截然相反的建議，從“ 將資料庫基礎設施擴充套件到必要”到“ 為什麼你不要分片”。那麼問題來了，你到底應該採納哪個建議呢？

什麼時候需要分片？答案是“依賴於具體情況”。

分片理論很簡單：選擇一個能均勻分佈資料的鍵key（列）。確保大部分查詢可以被該key定位到。這個理論很簡單，但一旦你將其落地到你的資料庫，實踐問題就變得凌亂了。

在Citus，我們幫助了數百個團隊研究如何分片資料庫。在這個過程中發現了一些關鍵模式。

分片的成功取決於三個關鍵屬性

三個關鍵屬性會影響專案的成功：

1. 工作負載型別。從事務機制到CRUD到資料倉儲。伸縮擴充套件時，這個維度是最被認可的。

2. 應用程式生命週期。您的資料庫中有多少張表（10?,100?,1000?）或您的應用程式在生產環境中執行有多長時間？在PostgreSQL上執行幾個月的應用程式將比執行很多年的應用程式更容易分片。

當您有成熟的應用程式時，這個因素變得至關重要。可悲的是，這個維度與其他兩個方面並不一致。事實上，大多數關於分片文章之所以得出相互矛盾的結論，是因為他們都是基於特定的一種應用上下文中提供的建議。

3.最重要的是：應用型別（B2B或B2C）

B2B的資料模型更適合分片。B2C應用程式，如亞馬遜和Facebook，分片則需要花費更多工作。接下來，我們選擇三家知名公司，談論他們的差異。

B2B示例：Salesforce

B2B應用的一個很好例子是CRM客戶管理軟體（Salesforce）。比如GE航空將成為Salesforce客戶。

在GE航空公司，有以下幾個資料表：
1. user是登陸使用者表
2. leads 是需要直接做生意的人員
3. contacts 代表生意關係
4. account代表有業務關係的

這幾個表看起來很複雜。如果你花更多的時間來研究它，那麼你會發現大多數表來自於customer表。你可以向這些表新增customer_id列，就是這麼簡單的變化，您的資料庫現在有了一個很好的分片鍵：customer_id。該分片鍵通常分佈均勻; 並且對資料庫的大多數查詢都會使用customer_id。

換句話說，如果您是B2B應用程式，業務資料的性質可以為您提供分片的基本優勢。

B2C示例：Amazon.com

Amazon.com是成熟B2C應用程式的一個很好的例子。如果您自己來建立Amazon.com網站，您可以考慮下面流程：

首先，使用者來到您的網站可以檢視您提供的產品，如書籍或電子產品。當使用者訪問產品頁面時，他們會看到與該產品相關的目錄資訊。

當您的使用者登入到您的網站時，他們就開始訪問與使用者相關的資料。使用者需要進行身份驗證，可以寫評論他們喜愛的產品，並可以新增產品專案到他們的購物車。使用者決定購買商品會下訂單。訂單處理完成，倉庫傳送貨物。

這裡涉及幾個資料表：
1.catalog 是產品目錄表
2.user是使用者表
3.order是訂單表
4.shipment是貨運表

當您要分片這些B2C資料型別時，其中一個解決方式是將您的應用程式重構為微服務。例如，提供catalog目錄資料的與目錄相關服務，以及擁有身份驗證和購物車資料的使用者相關服務。每個微服務只能訪問它們自己的資料庫，因此這些服務之間邊界其實定義了訪問底層資料的邊界。

這種分片方法與分割B2B應用程式在成本上相比是有明顯的不同。


Principles of Sharding for Relational Databases

相關文章