當(dāng)你的PG數(shù)據(jù)庫慢慢變大,你會(huì)怎么辦?
數(shù)據(jù)庫用戶都會(huì)面臨這樣的問題,當(dāng)系統(tǒng)剛剛開發(fā)好的時(shí)候,一切都是OK的,數(shù)據(jù)庫也沒啥性能問題,應(yīng)用跑得杠杠的。半年后也許是一兩年后,事情發(fā)生變化了。過去在 100 毫秒內(nèi)運(yùn)行的查詢現(xiàn)在只需要一秒鐘甚至幾秒鐘,剛開始的時(shí)候開發(fā)人員還是能夠應(yīng)付這些情況的,不過很快研發(fā)人員搞不定了,這時(shí)候PG DBA就需要上場(chǎng)了。對(duì)于很多DBA來說,優(yōu)化規(guī)模擴(kuò)展了數(shù)倍甚至數(shù)十倍的PostgreSQL數(shù)據(jù)庫是一件具有挑戰(zhàn)性的工作。
一般情況下,大多數(shù)系統(tǒng)在剛剛開始的時(shí)候往往因?yàn)殚_發(fā)時(shí)索引設(shè)計(jì)不夠合理而產(chǎn)生了大多數(shù)的性能問題,最初的優(yōu)化工作可以基于慢SQL的處理,通過索引的優(yōu)化可以度過你最初的具有挑戰(zhàn)性的日子。當(dāng)然,如果你的PG服務(wù)器使用了虛擬機(jī) ,那么增加硬件資源也可以是應(yīng)急的選項(xiàng)之一。不過總是擴(kuò)展硬件并非解決之道,解決數(shù)據(jù)庫的根本問題才是王道。因此在此階段并不建議你立即擴(kuò)容服務(wù)器,而是先開始整治慢SQL。
很多DBA在此階段喜歡自己動(dòng)手去一個(gè)個(gè)優(yōu)化SQL,而在一個(gè)略大一些的組織中,如果應(yīng)用開發(fā)團(tuán)隊(duì)比較強(qiáng)大,那么DBA在這個(gè)階段最好的策略是教會(huì)研發(fā)團(tuán)隊(duì)中的關(guān)鍵人物SQL優(yōu)化的一些簡(jiǎn)單的技巧,比如分析執(zhí)行計(jì)劃的合理性以及索引創(chuàng)建的規(guī)則。這樣研發(fā)團(tuán)隊(duì)會(huì)將一部分優(yōu)化工作承擔(dān)起來,而不是讓你陷入到這些枯燥并且不容易讓領(lǐng)導(dǎo)感受到你的價(jià)值的工作中,影響你在DBA本職中的工作效率。另外,由于研發(fā)人員更了解應(yīng)用的細(xì)節(jié),讓他們更多參與初期的SQL優(yōu)化工作,可以讓這件事干得更有針對(duì)性,效果也會(huì)更好。
如果你們企業(yè)規(guī)模不大,從Oracle遷移到PG后DBA的工作量不夠飽滿,干這些工作有助于讓你的工作量飽滿起來,那么你承接這些SQL優(yōu)化的工作也是可以的。
在這個(gè)階段,你需要對(duì)數(shù)據(jù)庫的參數(shù)做一次重新評(píng)估,因?yàn)槟壳跋到y(tǒng)的規(guī)模和剛上線時(shí)候已經(jīng)有了較大差別,shared_buffers,work_mem、max_parallel_workers等參數(shù)的設(shè)置是否合理會(huì)影響到某些SQL的執(zhí)行效率。bgwriter、walwriter、checkpoint相關(guān)的參數(shù)設(shè)置的不合理可能會(huì)影響到高并發(fā)下的數(shù)據(jù)庫整體性能。操作系統(tǒng)相關(guān)的參數(shù)設(shè)置不合理可能會(huì)讓硬件資源無法發(fā)揮最大的效益。當(dāng)系統(tǒng)很小的時(shí)候,這些參數(shù)哪怕設(shè)置得不太合理,也問題不大。而當(dāng)系統(tǒng)規(guī)模比較大的時(shí)候,這些參數(shù)也就需要精細(xì)化調(diào)優(yōu)了。
除了上述常規(guī)的工作,你還需要找到系統(tǒng)中的比較大的表,通過數(shù)據(jù)增長(zhǎng)量的情況來分析你是否需要優(yōu)化表的結(jié)構(gòu),如果某些大表數(shù)據(jù)量增長(zhǎng)很快,你要考慮開始優(yōu)化,將這些表改為分區(qū)表。在系統(tǒng)規(guī)模剛剛開始增大時(shí),這種工作還不太費(fèi)勁,等到表超級(jí)大的時(shí)候,做起來就費(fèi)勁了。這項(xiàng)工作是開發(fā)團(tuán)隊(duì)往往會(huì)忽視的,也是體現(xiàn)DBA價(jià)值的,因此這項(xiàng)工作一定要做好。
對(duì)于一些熱表,經(jīng)常會(huì)有熱塊爭(zhēng)用的表,哪怕表不夠大,在業(yè)務(wù)訪問性能不受影響的情況下(比如沒有大量的順序讀取),可以考慮改為HASH 分區(qū)表,從而為今后的長(zhǎng)期運(yùn)行排除掉一個(gè)地雷。如果該表不太適合HASH分區(qū),那么適當(dāng)減小這張表的填充因子,緩解一下熱塊沖突的影響也是很不錯(cuò)的。
實(shí)際上在這個(gè)階段,你已經(jīng)有能力判斷這個(gè)系統(tǒng)今后的規(guī)模了,如果你的評(píng)估是今后系統(tǒng)可能會(huì)導(dǎo)致單機(jī)負(fù)載過高,那么你可以向領(lǐng)導(dǎo)提出未來容量發(fā)展的評(píng)估結(jié)果,并給出建議。未來一兩年系統(tǒng)的擴(kuò)容和硬件改造優(yōu)化雖然并不一定馬上會(huì)開展,但是你需要給領(lǐng)導(dǎo)提出一個(gè)建議。如果簡(jiǎn)單擴(kuò)容無法解決問題,那么你可以建議優(yōu)化架構(gòu),將系統(tǒng)改為讀寫分離架構(gòu)來滿足未來的需求。因?yàn)檫@個(gè)優(yōu)化需要應(yīng)用架構(gòu)上的大調(diào)整,因此對(duì)于DBA來說,這個(gè)建議的提出越早越好。
在這個(gè)階段,你還需要仔細(xì)考慮當(dāng)前系統(tǒng)的高可用架構(gòu)、備份策略等方面是否存在優(yōu)化的需求。系統(tǒng)變得更大,也會(huì)變得更加重要,通過流復(fù)制構(gòu)建只讀備庫,完善物理備份和邏輯備份的方案等,也是DBA的本職工作。做好這些不僅僅讓你在企業(yè)中獲得同僚的尊重,這些工種成果也會(huì)成為你運(yùn)維這套數(shù)據(jù)庫系統(tǒng)的有力保障,這些工作一定不要掉以輕心,必須做好。