【一起來看看】mysql的使用中,為什麼我們幾乎不使用分割槽表?-八維網

在Oracle中,使用分割槽表是一種很自然的事情,資料庫容量基本都是500G起,大小在5T以上都是很常見的。

但是在MySQL的使用中,我們幾乎不使用分割槽表,今天有同學在群裡一起溝通,我就按照我的理解做了梳理。整體來說從功能上來說,Oracle有的大部分功能在MySQL分割槽表中基本存在,包括一些分割槽的細粒度管理。

所以如果單純從功能入手,確實難以找到很直接的理由來拒絕分割槽表。

【一起來看看】mysql的使用中,為什麼我們幾乎不使用分割槽表?-八維網

我覺得主要是使用模式的差異,我們不使用的主要原因是避免單庫儲存過大,而且分割槽表變更相對會比較麻煩,在MySQL側,我們的目標是讓資料庫更小巧輕量一些,可能更偏TP一些,我們目前是排除了分割槽表的設計,而且也明確寫進了開發規範,如果按照資料型別來說,狀態表,流水錶和配置表,這三種類型中也就只有流水日誌表的資料都是建議使用週期表的形式進行儲存,方便隨時擴充套件,表結構變更也方便T+1的變更模式

在這個基礎上,可以把這個問題轉化為,是使用分割槽表還是單表來儲存資料?這個問題我們調研過,目前來看,查詢複雜度的一些變更業務基本都能夠接受,而且風險覆蓋度要小一些(程式側也不能完全保證SQL一定好使不走全表掃描)目前我們實現週期表(日表,月表,周表,年表,季表)中的日表和月表的自動擴充套件,已經接管了300多個週期表的自動管理。

此外,資料流轉體系中,分割槽表的模式對於數倉體系也不夠友好,如果ETL直接抽資料,基本需要在過濾條件的部分做一些取捨,影響還是相對很大的。

   問題1:為啥Oracle分割槽表用的很常見  MySQL卻不推薦呢  挺疑問的。

因為是兩種不同的資料庫,拿MySQL當Oracle用,會有很多不如意的地方。Oracle單庫過T很正常,TP+AP很強,原生的HTAP的支援,MySQL的AP相對要弱很多,單庫過T是不建議,我們的容量規劃目前是按照300G的容量規格設計的,基本上從設計層面能夠做到冷熱資料分離和規避資料過度增長。

問題2:日表和月表什麼關係呢?月表是日表的聯合查詢還是資料映象?

日表和月表目前沒有直接的關聯,就是按照業務維度包括資料量進行綜合評估選定的,如果有的業務資料量不大,範圍查詢多一些,就推薦月表,如果資料量抖動大,資料量大,而且還會有變更操作,一般建議是日表,我們日表和月表的比例差不多是20:1

問題3:這些都是前期系統架構設計時規劃好的?有沒有後期改造的案例?如何去推動研發難度會不會很大

這個我認為不算前期規劃,算是迭代改進,我們提供的一個福利就是改造成日表後,日表的擴充套件和資料清理都是我們來幹了,業務很happy,而在以前,可能還會有手工維護Excel列表或者一些元資料配置的模式來記錄不同業務的表的擴充套件情況,有種手工記賬的感覺,如果DBA或者業務同學忘記了,基本碰上就是一次資料故障。

所以我們寫了自動管理的服務,包括單機和叢集中介軟體的週期表管理,基本上我們就不用手工干預了。

對於業務來說很大的痛點就是表如何擴充套件(有時候忘記了後果挺嚴重的),資料清理(如果不拆表,按照delete模式很痛苦)和表變更(T+1的模式對於業務來說是可用接受的,對於DBA完全可控)

小結:

我們不使用分割槽表,一方面是業務所需,另一方面我們提供了週期表解決了業務痛點,所以也算是一拍即合的一種策略。

頂部