1.概述

我們都知道隨著業務系統的發展和使用，數據庫存儲的業務數據量會越來越大，逐漸成為了業務系統的瓶頸。在阿里巴巴開發手冊中也建議：單表行數超過500萬行或者單表容量超過2GB才推薦進行分庫分表，如果預計三年后數據量根本達不到這個級別，請不要在創建表時就分庫分表。數據庫最終都是存儲在磁盤上，隨著數據量變大，會導致數據操作變得緩慢，無論是計算還是IO，但是話又說回來，單表數據量大就一定要進行分庫分表操作嗎？答案是否定的，因為分庫分表本身是一個“很重”的操作，這里就不賣關子了，直接來看看分庫分表帶來的以下問題和挑戰：

• 重構適配系統  本身我們的業務系統不可能一開始開發上線的時候就會分庫分表，都是隨著系統使用和時間推移數據量日益膨脹才考慮的，進行分庫分表我們業務服務項目代碼需要從單一數據庫表適配成多庫多表，這是一次極其繁重的重構任務，還涉及到數據遷移、備份、擴容等操作問題，該任務上線鏈路之長、風險之大不言而喻，這也是很多小公司即使數據量上來了也不會馬上分庫分表的原因吧。
• 事務問題  目前數據庫只能夠實現本地事務，也就是在同一個數據庫中，可以允許一組操作要么全都正確執行，要么都不執行，從而確保數據庫的一致性。單從分區角度出發，實際上仍然是一張表，一個庫中，它不會存在事務一致性的問題，但是會使得事務變得非常復雜。而分庫分表會涉及到分布式事務，目前數據庫并不支持跨庫事務，所以在這一塊需要解決分布式事務可能帶來的不一致性
• 分頁、排序、聚合函數問題   分頁需要按照執行的字段進行排序，當排序字段就是分片字段的時候，通過分片規則就比較容易定位到指定的分片；當排序字段并非分片字段的時候，就需要在不同分區、分表中進行排序并且返回，然后再將不同分區、分表中返回的結果集進行匯總和再次排序，最終得到返回結果。取得頁數越多，性能受影響也就越大。因為在分區、分表的時候都已經限定了分片字段，而其他字段是跟著分片的字段被分到不同的區域或者表中，這樣各個分區、分表中的數據可能是隨機的，為了排序的準確性，需要將所有分區、分表節點的前的數據都排好序做合并，最后進行整體排序，這樣的操作是非常耗費CPU和內存資源的，所以在分區、分表的情況下、分頁數越大，系統的性能也會越差。同樣、在使用聚合函數，如Max、Min、Sum、Count進行計算的時候，也會像排序那樣在每個分區、分表執行相應的函數，然后再將各個分區、分表的結果集進行匯總和再次計算，最終將結果返回。
• 全局主鍵避免重復  單表主鍵id自增能夠保證id不重復，但是分庫分表之后，多張表就不能保證主鍵id不重復了，這時候就要使用分布式id算法進行生成。
• 數據遷移、擴容問題  隨著數據持續增加分表后還需要進行動態新增表時，這個時候就要考慮數據遷移以及擴容問題。一般做法是先讀出歷史數據，然后按照指定的分表規則再將數據寫入各個分表中。這本身就是繁雜之事。

當然以上問題并不是說分庫分表是一個不可取的方案，現在分庫分表方案在很多公司系統都有應用的，這里想表達的是需要根據個人公司業務系統數據特點，綜合評估做權衡來選擇解決數據量大的實施方案。

項目推薦：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企業級系統架構底層框架封裝，解決業務開發時常見的非功能性需求，防止重復造輪子，方便業務快速開發和企業技術棧框架統一管理。引入組件化的思想實現高內聚低耦合并且高度可配置化，做到可插拔。嚴格控制包依賴和統一版本管理，做到最少化依賴。注重代碼規范和注釋，非常適合個人學習和企業使用

Github地址：https://github.com/plasticene/plasticene-boot-starter-parent

Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent

微信公眾號：Shepherd進階筆記

交流探討qun：Shepherd_126

2.業務數據量大的解決方案

2.1 數據歸檔

來分析一個美團業務場景：我們日常每天點外賣，平時會去查看一年前的訂單，看看一年前吃了什么嗎？答案是幾乎不會，或者說這種查詢的請求量比較小，出現這種請求大概是有人問你很早之前點的那家外賣好吃，但是你不喜歡記不得了，你幫她查找一下的場景吧~~。由此可見，我們可以根據這一特點進行數據歷史歸檔，即數據做冷、熱區分存儲。當然這個區分時限要根據自身系統數據特點來指定時限是一年還是半年....這樣就能保證我們高頻查詢的熱數據量不大了。

在查詢歷史數據表時，可以限制查詢條件如必須選擇日期范圍，日期范圍不能超過N個月等等從而減輕查詢壓力。處理歷史存量數據比較簡單，因為歷史數據一般不會變更了，所以一般只需要兩個步驟進行歸檔：

• 遷移滿足限定數據到指定歷史歸檔表
• 根據主鍵分批刪除業務原表數據，從而降低業務數據量

這里需要強調一下，不能一次性刪除所有數據，因為數據量太大可能會引發超時，鎖表，長事務等問題，而是應該根據ID分批刪除，例如每次刪除500或1000條數據。操作步驟如下：

SELECT MAX(id) AS maxId FROM t WHERE create_time < '指定時間'

查出滿足歸檔條件的數據最大id，接下來就可以分批歸檔和刪除了，初始化 startId=0，每次歸檔500條

select * into t_bak from t where id > startId and id <= maxId limit 500

查詢歸檔表獲取最大id：maxBakId，賦值給startId方便下次分批歸檔刪除

select max(id) from t_bak

數據刪除：

delete from t where id <= maxBakId

重復上面的歸檔刪除操作，直至startId到maxId結束

2.2 讀寫分離和熱點緩存

大部分的業務系統場景都是讀多寫少，讀寫比一般都在幾十左右，平均每發生幾十次查詢請求，才有一次更新請求。換句話來說，數據庫需要應對的絕大部分請求都是只讀查詢請求。針對這種情況我們可以通過讀寫分離方案來降低數據庫壓力。

圖片

主庫負責執行應用程序發來的所有數據更新請求，然后異步將數據變更實時同步到所有的從庫中去，這樣，主庫和所有從庫中的數據是完全一樣的。多個從庫共同分擔應用的查詢請求。

對于一些高頻訪問的熱點數據，我們可以提前預處理使用redis緩存，這樣也可以有效降低數據庫的壓力。

2.3 同步異構數據源

我們知道MySQL會隨著數據量增大而查詢變慢，那么我們換成其他數據源來完成OLAP查詢場景不就得了。特別是在當下大數據時代，現在互聯網公司一般都具備與之規模相對應的大數據服務或者平臺，那么作為業務開發者要善于應用公司大數據能力，減輕業務數據庫壓力。比如我們可以把數據同步到ES、HBASE等平臺。

使用elasticsearch來實現海量數據搜索就是一個不錯的選擇，elasticsearch是一個基于Lucene的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java開發的，并作為Apache許可條款下的開放源碼發布，是當前流行的企業級搜索引擎。能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。但是如何實現MySQL數據同步elasticsearch呢？

答案是阿里的開源項目Canal，就是用來解決異構數據源數據同步這個問題的，Canal項目利用了MySQL數據庫主從同步的原理，將Canal Server模擬成一臺需要同步的從庫，從而讓主庫將binlog日志流發送到Canal Server接口。Canal項目對binlog日志的解析進行了封裝，我們可以直接得到解析后的數據，而不需要理會binlog的日志格式。而且Canal項目整合了zookeeper，整體實現了高可用，可伸縮性強

圖片

2.4 分庫分表

如果通過以上：歷史數據歸檔、數據同步異構數據源、讀寫分離、熱點緩存都不能解決MySQL單表數據壓力的，這時我們只能拆分數據表，即把單庫單表數據遷移到多庫多表中。這也是一線流量互聯網公司需要面對的，你試想一下淘寶雙11那幾天要上架多少商品，產生多少訂單，這已經不是前面的方案所能解決了，只能分庫分表了。當然分庫分表是一個復雜的操作，也不是三言兩語就能全面講清楚的，且也不是我們今天主要議題，所以我這里粗略概述一下，感興趣的可自行查閱相關資料。

垂直拆分

垂直拆分就是按照業務拆分，我們將電商數據庫拆分成三個庫，訂單庫、商品庫。支付庫，訂單表在訂單庫，商品表在商品庫，支付表在支付庫。這樣每個庫只需要存儲本業務數據，物理隔離不會互相影響。

水平拆分

按照垂直拆分方案，現在我們已經有三個庫了，平穩運行了一段時間。但是隨著業務增長，每個單庫單表的數據量也越來越大，逐漸到達瓶頸。

這時我們就要對數據表進行水平拆分，所謂水平拆分就是根據某種規則將單庫單表數據分散到多庫多表，從而減小單庫單表的壓力。

水平拆分策略有很多方案，最重要的一點是選好ShardingKey，也就是按照哪一列進行拆分，怎么分取決于我們訪問數據的方式。

比如我們可以根據時間范圍分片，根據創建時間分配到不同的表中。也可以根據哈希分表，哈希分片可以較為均勻將數據分散在數據庫中。我們現在將訂單庫拆分為4個庫編號為[0,3]，每個庫4張表編號為[0,3]，根據分布式id%編號落庫，當然也有其他分片方案，這取決于你們公司業務數據特點。

3.如何實時同步數據到elasticsearch支持海量查詢

我一開始就強調了分庫分表帶來的問題，可見今天的重點肯定不是采用分庫分表來解決數據量大的問題的，所以我接下來來講講我司的解決方案：數據歸檔+讀寫分離+同步異構數據源

數據歸檔可以有效降低數據庫數據量，讀寫分離可以降低單數據庫的讀寫壓力，異構數據源es滿足日常查詢性能要求。

數據歸檔的操作步驟前面說過了，至于數據庫讀寫分離實現方案等后續有時間再分析一波，今天主要講講如何高效實時同步elasticsearch滿足查詢要求。直接看架構圖：

圖片

數據同步elasticsearch大概有兩種：

1.針對代碼中進行數據庫的增刪改操作時，同時進行elasticsearch的增刪改操作。這種方式代碼侵入性強，耦合度高，實時性高，改造起來比較痛苦，因為你不能錯過任何一個增刪改的地方同步操作es，否則就會出現數據不一致問題。

2.利用監聽mysql binlog同步，實時性強，對于應用無任何侵入性，且性能更好，不會造成資源浪費。正好阿里巴巴開源的canal就是干這個的，完美解決問題。通過上面的架構圖知道可以通過canal client拿到canal server對binlog的解析直接同步到es，但是這種方式處理比較慢，等于我們是一條一條的去同步，很多情況下es的索引表是一張大寬表，是來自MySQL幾張表join的信息，這要求我們同步的時候還要根據主鍵通過join sql語句查出數據再同步，自然就更慢了。所以要使用消息隊列kafka進行數據削峰填谷，批量操作是保證實時性的關鍵。

4.總結

以上全部就是我們對海量數據實時搜索的解決方案淺析，各有利弊。我們可以根據自身的業務數據情況選擇合適的方案即可，切勿動不動就來分庫分表，顯得有點不知深淺。

本文轉載自微信公眾號「Shepherd進階筆記」，可以通過以下二維碼關注。轉載本文請聯系公眾號。