根據業務初步預估訂單業務量，每天500萬的數據。我們將訂單數據劃分為了2大類型：分別為熱數據和冷數據。

熱數據：1個月內的訂單數據，查詢實時性較高;

冷數據：歸檔訂單數據，查詢頻率不高;

根據實際業務場景，用戶基本不會操作或查詢2個星期以上的數據，如果這部分數據存儲在DB中，那么成本會非常高，而且也不方便維護。另外，如果有特殊情況需要訪問歸檔數據，可以走離線數據查看。

對于這2類數據，規劃如下：

熱數據：使用MySQL進行存儲，分庫分表；

冷數據：ES 或 TiDB或Hive存儲；

按業務垂直拆分

按照訂單使用者拆分為3個數據庫，客戶端、商家端、渠道端，目的是分散壓力，提高吞吐量，互不影響

業務分庫

有人會問，下單的時候該怎么辦呢？

下單時只寫客戶庫，寫成功后，往消息隊列里面發送兩個消息，一個是寫商家庫、一個是寫渠道庫

分表策略

在訂單表中，可以將uid(用戶ID)字段作為sharding key。假設單個庫需要分配 10 張表可以滿足業務需要，可以簡單地取模計算出訂單分配到哪張表。

一旦確定sharding key，就只能根據sharding key定位到子表進而查詢該子表下的數據；如果確實想根據user_id 去查詢相關訂單，那么需要先根據user_id 查詢映射到的order_id list，然后再根據order_id list 再查詢。

分庫策略

數據庫分表能夠解決單表數據量很大的時候數據查詢的效率問題，但是無法給數據庫的并發操作帶來效率上的提高，因為分表的實質還是在同一個數據庫Server上進行的操作，很容易受數據庫Server IO 性能的限制。

因此， 可以將數據進行分庫操作，可以解決單臺數據庫Server的性能瓶頸。

分庫策略與分表策略的實現很相似，最簡單的都是可以通過取模的方式進行路由。

uid % 數據庫數量，如：109005 % 16 = 13，分配到第13個數據庫

分庫分表結合使用策略

數據庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單臺數據庫的并發訪問壓力問題。有時候，我們需要同時考慮這兩個問題，因此，我們既需要對單表進行分表操作，還需要進行分庫操作，以便同時擴展系統的并發處理能力和提升單表的查詢性能，就是我們使用到的分庫分表。

如果分庫和分表都使用同一個拆分鍵進行 Sharding 時，根據拆分鍵的鍵值按總的分表數(分庫數x分表數)取余。

分庫分表

整體架構

圖片發自簡書App

將訂單請求分為查詢和更新請求，更新請求比較簡單，就是根據分庫分表規則寫入db即可。

對于查詢請求，我們需要計算出查詢的是熱數據還是冷數據，根據查詢的時間范圍計算出查詢的是熱數據還是冷數據。或者無法確定熱數據、冷數據，就都走ES 或TiDB。

另外架構圖中的冷數據指的是近期1年的數據，如果是查詢一年前的數據，建議直接離線查hive即可。

圖中有一個定時Job，主要用來定時遷移訂單數據，需要將冷數據分別遷移到ES和hive中。

總結

以上是生活随笔為你收集整理的mysql 多维度分表_亿级订单数据分库分表设计方案（满足多维度查询：订单号、用户、商家、渠道）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。