訂單資料如何劃分
我們可以將訂單資料劃分成兩大型別：分別是熱資料和冷資料。
可能這裡有個疑惑為什麼要將冷資料分成兩類，因為根據實際場景需求，使用者基本不會去檢視1年前的資料，如果將這部分資料還儲存在db中，那麼成本會非常高，而且也不便於維護。另外如果真遇到有個別用戶需要檢視1年前的訂單資訊，可以讓使用者走離線資料檢視。
對於這三類資料的儲存，目前規劃如下：
3.1、按業務拆分
在業務初始階段，為了加快應用上線和快速迭代，很多應用都採用集中式的架構。但是隨著業務系統的擴大，系統匾額越來越複雜，越來越難以維護，開發效率變得越來越低，並且對資源的消耗也變得越來越大，透過硬體提高系統性能的成本會變得更高。
通常一般的電商平臺，包含了使用者、商品、訂單等幾大模組，簡單的做法是在同一個庫中分別建4張表，如下圖所示：
但是隨著業務的提升，將所有業務都放在一個庫中已經變得越來越難以維護，因此我們建議，將不同業務放在不同的庫中，如下圖所示：
由圖中我們可以看出，我們將不同的業務放到不同的庫中，將原來所有壓力由同一個庫中分散到不同的庫中，提升了系統的吞吐量。
3.2、分庫與分表
我們知道每臺機器無論配置多麼好它都有自身的物理上限，所以當我們應用已經能觸及或遠遠超出單臺機器的某個上限的時候，我們惟有尋找別的機器的幫助或者繼續升級的我們的硬體，但常見的方案還是透過新增更多的機器來共同承擔壓力。
我們還得考慮當我們的業務邏輯不斷增長，我們的機器能不能透過線性增長就能滿足需求？因此，使用資料庫的分庫分表，能夠立竿見影的提升系統的效能，關於為什麼要使用資料庫的分庫分表的其他原因這裡不再贅述，主要講具體的實現策略。
（1）分表策略
我們以訂單表為例，在訂單表中，訂單id肯定是不可重複的，因此將該欄位當做shard key 是非常適合的,其他表類似。假設訂單表的欄位如下：
1create table order(2 order_id bigint(11) ,3
我們假設預估單個庫需要分配100個表滿足我們的業務需求，我們可以簡單的取模計算出訂單在哪個子表中，例如： order_id % 100,
這時候可能會有人問了，如果我根據order_id 進行分表規則，但是我想根據user_id 查詢相應的訂單，不是定位不到哪個子表了嗎，的確是這樣，一旦確定shard key，就只能根據shard key定位到子表進而查詢該子表下的資料；如果確實想根據user_id 去查詢相關訂單，那應該將shard key設定為user_id, 那分表規則也相應的變更為： user_id % 100;
（1）分庫實現策略
資料庫分表能夠解決單表資料量很大的時候資料查詢的效率問題，但是無法給資料庫的併發操作帶來效率上的提高，因為分表的實質還是在一個數據庫上進行的操作，很容易受資料庫IO效能的限制。
因此，如何將資料庫IO效能的問題平均分配出來，很顯然將資料進行分庫操作可以很好地解決單臺數據庫的效能問題。
分庫策略與分表策略的實現很相似，最簡單的都是可以透過取模的方式進行路由。
我們還是以order表舉例，
例如：order_id % 庫容量,
如果order_id 不是整數型別，可以先hash 在進行取模，
例如： hash(order_id) % 庫容量
（3）分庫分表結合使用策略
資料庫分表可以解決單表海量資料的查詢效能問題，分庫可以解決單臺數據庫的併發訪問壓力問題。有時候，我們需要同時考慮這兩個問題，因此，我們既需要對單表進行分表操作，還需要進行分庫操作，以便同時擴充套件系統的併發處理能力和提升單表的查詢效能，就是我們使用到的分庫分表。
如果使用分庫分表結合使用的話，不能簡單進行order_id 取模操作，需要加一箇中間變數用來打散到不同的子表，公式如下：
中間變數 ＝ shard key %（庫數量*單個庫的表數量）;2庫序號 ＝ 取整（中間變數／單
例如：資料庫有10個，每一個庫中有100個數據表，使用者的order_id＝1001，按照上述的路由策略，可得：
這樣的話，對於order_id＝1001，將被路由到第1個數據庫的第2個表中(索引0 代表1，依次類推)。
從圖中我們將請求分成read和write請求，write請求比較簡單，就是根據分庫分表規則寫入db即可。
對於read請求，我們需要計算出查詢的是熱資料還是冷資料，一般order_id生成規則如下，“商戶所在地區號+時間戳+隨機數”，我們可以根據時間戳計算出查詢的是熱資料還是冷資料，（當然具體業務需要具體對待，這裡不再詳細闡述）
另外架構圖中的冷資料指的是3個月~12個月前的資料，如果是查詢一年前的資料，建議直接離線查hive即可。
圖中有一個定時Job，主要用來定時遷移訂單資料，需要將冷資料分別遷移到ES和hive中。
訂單資料如何劃分
我們可以將訂單資料劃分成兩大型別：分別是熱資料和冷資料。
熱資料：3個月內的訂單資料，查詢實時性較高;冷資料A：3個月 ~ 12個月前的訂單資料，查詢頻率不高;冷資料B：1年前的訂單資料，幾乎不會查詢，只有偶爾的查詢需求;可能這裡有個疑惑為什麼要將冷資料分成兩類，因為根據實際場景需求，使用者基本不會去檢視1年前的資料，如果將這部分資料還儲存在db中，那麼成本會非常高，而且也不便於維護。另外如果真遇到有個別用戶需要檢視1年前的訂單資訊，可以讓使用者走離線資料檢視。
對於這三類資料的儲存，目前規劃如下：
熱資料： 使用mysql進行儲存，當然需要分庫分表；冷資料A: 對於這類資料可以儲存在ES中，利用搜索引擎的特性基本上也可以做到比較快的查詢；冷資料B: 對於這類不經常查詢的資料，可以存放到Hive中；三、MySql 如何分庫分表3.1、按業務拆分
在業務初始階段，為了加快應用上線和快速迭代，很多應用都採用集中式的架構。但是隨著業務系統的擴大，系統匾額越來越複雜，越來越難以維護，開發效率變得越來越低，並且對資源的消耗也變得越來越大，透過硬體提高系統性能的成本會變得更高。
通常一般的電商平臺，包含了使用者、商品、訂單等幾大模組，簡單的做法是在同一個庫中分別建4張表，如下圖所示：
但是隨著業務的提升，將所有業務都放在一個庫中已經變得越來越難以維護，因此我們建議，將不同業務放在不同的庫中，如下圖所示：
由圖中我們可以看出，我們將不同的業務放到不同的庫中，將原來所有壓力由同一個庫中分散到不同的庫中，提升了系統的吞吐量。
3.2、分庫與分表
我們知道每臺機器無論配置多麼好它都有自身的物理上限，所以當我們應用已經能觸及或遠遠超出單臺機器的某個上限的時候，我們惟有尋找別的機器的幫助或者繼續升級的我們的硬體，但常見的方案還是透過新增更多的機器來共同承擔壓力。
我們還得考慮當我們的業務邏輯不斷增長，我們的機器能不能透過線性增長就能滿足需求？因此，使用資料庫的分庫分表，能夠立竿見影的提升系統的效能，關於為什麼要使用資料庫的分庫分表的其他原因這裡不再贅述，主要講具體的實現策略。
（1）分表策略
我們以訂單表為例，在訂單表中，訂單id肯定是不可重複的，因此將該欄位當做shard key 是非常適合的,其他表類似。假設訂單表的欄位如下：
1create table order(2 order_id bigint(11) ,3
我們假設預估單個庫需要分配100個表滿足我們的業務需求，我們可以簡單的取模計算出訂單在哪個子表中，例如： order_id % 100,
這時候可能會有人問了，如果我根據order_id 進行分表規則，但是我想根據user_id 查詢相應的訂單，不是定位不到哪個子表了嗎，的確是這樣，一旦確定shard key，就只能根據shard key定位到子表進而查詢該子表下的資料；如果確實想根據user_id 去查詢相關訂單，那應該將shard key設定為user_id, 那分表規則也相應的變更為： user_id % 100;
（1）分庫實現策略
資料庫分表能夠解決單表資料量很大的時候資料查詢的效率問題，但是無法給資料庫的併發操作帶來效率上的提高，因為分表的實質還是在一個數據庫上進行的操作，很容易受資料庫IO效能的限制。
因此，如何將資料庫IO效能的問題平均分配出來，很顯然將資料進行分庫操作可以很好地解決單臺數據庫的效能問題。
分庫策略與分表策略的實現很相似，最簡單的都是可以透過取模的方式進行路由。
我們還是以order表舉例，
例如：order_id % 庫容量,
如果order_id 不是整數型別，可以先hash 在進行取模，
例如： hash(order_id) % 庫容量
（3）分庫分表結合使用策略
資料庫分表可以解決單表海量資料的查詢效能問題，分庫可以解決單臺數據庫的併發訪問壓力問題。有時候，我們需要同時考慮這兩個問題，因此，我們既需要對單表進行分表操作，還需要進行分庫操作，以便同時擴充套件系統的併發處理能力和提升單表的查詢效能，就是我們使用到的分庫分表。
如果使用分庫分表結合使用的話，不能簡單進行order_id 取模操作，需要加一箇中間變數用來打散到不同的子表，公式如下：
中間變數 ＝ shard key %（庫數量*單個庫的表數量）;2庫序號 ＝ 取整（中間變數／單
例如：資料庫有10個，每一個庫中有100個數據表，使用者的order_id＝1001，按照上述的路由策略，可得：
這樣的話，對於order_id＝1001，將被路由到第1個數據庫的第2個表中(索引0 代表1，依次類推)。
三、整體架構設計從圖中我們將請求分成read和write請求，write請求比較簡單，就是根據分庫分表規則寫入db即可。
對於read請求，我們需要計算出查詢的是熱資料還是冷資料，一般order_id生成規則如下，“商戶所在地區號+時間戳+隨機數”，我們可以根據時間戳計算出查詢的是熱資料還是冷資料，（當然具體業務需要具體對待，這裡不再詳細闡述）
另外架構圖中的冷資料指的是3個月~12個月前的資料，如果是查詢一年前的資料，建議直接離線查hive即可。
圖中有一個定時Job，主要用來定時遷移訂單資料，需要將冷資料分別遷移到ES和hive中。