MySQL在Data Warehouse應用的一些指引

02-05

我想許多公司的研發或者DBA都會碰到一個問題，MySQL在處理海量數據上往往力不從心，硬體是一個因素，自身缺乏對複雜SQL處理，也是一個硬傷。但事實也沒有那麼糟糕，MySQL對於絕大部分公司來說，也是夠用的，如果每個公司都創建自己的一套海量數據分析平台，使用hadoop等各類分析框架/平台/工具，反而難以取得好的收益。我們投入到設計/策略的時間越多，我們越能獲得更好的投入/產出比。充分利用現有的技術和標準的產品/組合，往往可以取得更好的效益，除非事實證明，你需要在某個時間點重構你的分析平台了。

許多項目在上線的時候，其實並沒有充分想好數據的處理和分析，如果項目進展很快，數據量爆炸式增長，基於原有的數據做分析，往往會出現一些問題，所以在項目上線之前，就考慮好數據的記錄和分析是有必要的，並不是要求每個業務，都單獨搭建自己的一個統計庫/分析平台，但你需要有所準備。

如下是一些OLAP的大的原則和方向，

1、MySQL實例控制在幾個2個T以內，是DBA們比較贊同的策略，OLAP資料庫可以大到幾個T，但是備份之類的操作很耗時，percona工具之xtrabackup可以比較好的備份大資料庫；

2、對於數據分析，應該盡量避免重複計算，對於報表之類的應用，最好定期生成統計表，基於統計表，可以快速的查看統計數據，而不需要從原始數據表裡去掃描統計大量數據；

3、對於舊數據的歸檔/清理，需要考慮，理論上來說，如果你的設計比較完善，絕大部分時候，你已經不需要原始數據了，保留統計表數據即可，你可以定期把原始數據清理掉。原始數據也可以以其他的方式，比如日誌的方式，存儲在其他介質；

4、為了節省空間，我們可能會設計一些代碼/映射表，通過在一些大表中僅僅存儲代碼/數字的方式，我們可以大大減少存儲的空間，對於oltp業務，我覺得沒有必要這樣做，程序/數據的可讀性，自然會更重要，但對於OLAP資料庫，這樣真的可能節省大量磁碟空間；

5、索引的濫用可能會是一個問題，如果你擁有大量的數據，索引帶來的大量隨機讀其實效率很低，也延緩了數據插入的速率。你需要仔細檢查，確保僅僅創建需要的索引；

6、使用LOAD DATA 的方式載入數據很快，值的優先考慮，你也可以使用批量insert的方式，one by one的導入大量數據的方式太過低效，不可取。當然使用insert批量插入數據也沒有必要一次性插入太多記錄，100～1000記錄每個語句一般是可以接受的；

7、如何避免導入數據對於線上業務的影響需要考慮，你可能需要中間表，你可能需要額外的從庫；

8、對於超大規模的海量數據，單個節點可能難以容納和處理，使用分區表某種程度上可以加快一些分析/查找，但仍然受限制於單個節點，在單個節點已經無法處理海量數據的時候，你應該考慮sharding的策略。