mysql大表的解決方案，及Hive分頁查詢

先說一下遇到的問題，然後給出自己的解決方案，雖然不一定是最佳的解決方法，但是目前確實解決了公司的大表資料問題，如果其他小夥伴有更好的解決方法，也請多多交流，給出自己的解決方法。

1.mysql表查詢資料量較大（最大的一張表已經達到33億條資料，整個mysql已經達到2.9t的資料儲存），

2.mysql表每日新增資料量較大（增量最大的表，每日新增資料量在4千萬條左右的資料）

3.需要支援事務操作，部分表需要支援更新操作。

4.支援複雜操作，包括模糊，排序，分組統計和分頁等操作。

5.低延遲，使用者選擇的任務條件查詢，響應時間應該控制在3-5s。

6.實時資料的寫入和查詢操作,目前實時資料每10分鐘處理一次，大概400g左右的資料。

從上面很容易看出來我們遇到的，

1.單錶資料量較大，已經無法支撐前台部分業務的正常操作；

對於我們的mysql表，我們儲存的大部分都是統計資料，因為早期資料量較少，統計能力有限，以及考慮到和前台互動較頻繁，所以一直儲存在關係型資料庫中，才造成目前遇到這種的窘境，已經到不了不改變的的地步，因為資料的增量越來越大。

我們的解決步驟和方法：

1.首先，我們第乙個考慮的時候結合業務，前面使用者的操作

2.對錶中資料進行了檢查和審查之後，發現大資料中經常遇到的2/8定律，20%的使用者佔了80%的資料。我們考慮分庫和分表操作，將部分資料量較大的使用者遷入到其他伺服器的資料庫中，但是增大的前端視覺化部門的工作壓力，同時統計部門的統計程式需要全部調整，用來區分不同的使用者。

3.使用大資料技術解決，將離線資料，全部遷移到hive中，按天分割槽管理，使用presto做複雜查詢，實時資料保留，繼續寫入mysql，對於有更新操作的表，直接寫入到hbase中，使用phoenix處理。

在遷移資料的過程中，我們剛開始使用的是sqoop導取mysql資料到hive，動態分割槽，後來發現這樣有一些弊端，因為無法解決spark寫入mysql的效能問題，我們對spark進行了各種優化，將資料的處理時間控制在了5分鐘左右，但是卻經常在寫mysql的時候需要將近1個鐘頭的時間，於是直接將離線統計全部直接直接寫入hdfs，現在基本上分析和寫入時間在10分鐘左右。同時也解決了資料擠壓的問題。

最後問題解決了，目前我們做了乙個中間微服務，使用springboot做查詢，分為兩部分處理，

a.使用者對歷史資料（昨天，最近1周或最近1個月，以及指定任意時間段區間，除今天之外）的操作，我們均採用presto操作;

b.使用者查詢今天的實時操作，我們直接讀取mysql中的資料，目前單錶資料量最大在千萬級，所以msyql完全能支撐的住，而且效能還不錯。對於使用者指定較長時間段的查詢，包括實時今天的資料操作時，我們採取，presto+mysql同時分析處理，然後通過程式對資料進行最後統一的合併，分頁，排序，這個目前還在優化，以達到準確性在可承受範圍內。

以上是我們的解決方法，php人員直接呼叫我們的介面，不需要關心我們底層使用的什麼技術（當然這個解決方法只是基於我們目前的業務場景的解決方法，不一定是最優的解決方案，但是目前給我們統計大量的資料湧進來時，提供了一定的緩衝時間），同時將視覺化和底層資料剝離開，如果目前的方法達到瓶頸，再次無法滿足效能的要求，後面考慮使用其他技術處理，最主要的是這次調整降低了公司的經濟支出，不用被動的去公升級資源配置。

最後，給出了乙個hive中分頁的查詢操作，主要使用到row_number和between，and。

select c.* 
from( 
select row_number() over (order by b.ev_paras_value asc ) as sort_field, b.* 
from (
from  (
sum(ev_paras_uv) as paras_uv, 
sum(ev_paras_count) as paras_count 
from aldstat_event_paras_partition 
where 1=1  
and day_time in ('2018-08-01') 
and event_key='bbbbbbbb' 
and ev_paras_name like '%name%' 
order by a.ev_paras_value asc ) b ) c 
where c.sort_field between 1 and 30

mysql大表的解決方案，及Hive分頁查詢

mysql 解決方案 Mysql解決方案

MySQL 刪除大表的效能問題解決方案

鎖表初步理解及解決方案

mysql大表的解決方案，及Hive分頁查詢

mysql 解決方案 Mysql解決方案

MySQL 刪除大表的效能問題解決方案

鎖表初步理解及解決方案

相關推薦