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