建站
咨詢
售后
建站咨詢
新聞中心
大家用Oracle數(shù)據(jù)庫的時候，根本不需要過多的去考慮數(shù)據(jù)庫物理結(jié)構(gòu)以及OS物理結(jié)構(gòu)方面的優(yōu)化。因?yàn)镺racle把一切都幫我們做好了，只需要交給Oracle足夠容量，足夠能力的物理資源就一切OK了。不過作為三十年前就開始使用Oracle數(shù)據(jù)庫的我們這一代DBA，還是經(jīng)歷過很多這樣的優(yōu)化案例的。在那個年代，曾經(jīng)通過底層存儲的重新條帶化設(shè)計(jì)，讓一套IO負(fù)載極高的數(shù)據(jù)庫系統(tǒng)的批處理作業(yè)性能提高數(shù)倍。
我們提供的服務(wù)有：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、市北ssl等。為超過千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的市北網(wǎng)站制作公司
現(xiàn)在我們?nèi)绻皇褂肙racle數(shù)據(jù)庫了，我們要把應(yīng)用從Oracle遷移到國產(chǎn)數(shù)據(jù)庫上了，那么這些老手藝可能又有些作用了。不過與那個時代不同的是，現(xiàn)在硬件的能力已經(jīng)百倍的提升了，存儲系統(tǒng)的全局IO打散能力也成為了標(biāo)配，因此再也不需要像我在二十多年前那樣為了一點(diǎn)點(diǎn)的IOPS去精打細(xì)算了。
今天這個話題雖然我已經(jīng)把討論范圍縮小到了物理結(jié)構(gòu)優(yōu)化上，不過還是太大，我不大可能在一個一千多字的文章里把所有的問題都講清楚，因此我們今天還是縮小到一個比較小的話題上吧，那就是如何通過底層物理結(jié)構(gòu)的優(yōu)化讓關(guān)鍵業(yè)務(wù)系統(tǒng)在PG類數(shù)據(jù)庫上平穩(wěn)運(yùn)行。這里講的是PG類數(shù)據(jù)，除了社區(qū)版的PG外，還有大量基于PG的開源、國產(chǎn)數(shù)據(jù)庫產(chǎn)品，包括華為的GAUSSDB系列，瀚高、金倉、神通、優(yōu)炫、亞信ANTDB、中國移動磐維等，都是PG類數(shù)據(jù)庫。甚至今天我討論的部分內(nèi)容對于MYSQL、達(dá)夢、SQL SERVER等沒有使用DIO的數(shù)據(jù)庫也是有一定作用的。
最近我經(jīng)常聽說某些客戶把數(shù)據(jù)庫從Oracle遷移到國產(chǎn)數(shù)據(jù)庫上后，一些關(guān)鍵業(yè)務(wù)忽快忽慢，檢查執(zhí)行計(jì)劃也沒啥問題，操作系統(tǒng)層面也沒有明顯的瓶頸或者慢的因素。實(shí)際上這與數(shù)據(jù)庫沒有使用DIO有很大的關(guān)系。對于沒有使用DIO的系統(tǒng)，當(dāng)數(shù)據(jù)沒有在DB CACHE中命中的時候，會產(chǎn)生物理讀。不過這個物理讀并不一定真正的從物理存儲介質(zhì)上讀取，如果數(shù)據(jù)在LINUX的OS CACHE里，那么可以直接從CACHE中獲取，這種物理讀是很快的，如果OS CACHE沒有命中，那么就只能真正的從物理存儲介質(zhì)中去讀取了，相對于直接從內(nèi)存中讀取，這種物理讀是較慢的。因?yàn)镺S CACHE沒辦法按照我們的數(shù)據(jù)庫訪問需求去緩沖數(shù)據(jù)，因此OS CACHE的目的性并不強(qiáng)。這種忽快忽慢大多數(shù)集中在讀操作上的，不過有時候?qū)懸矔霈F(xiàn)抖動，那是因?yàn)镺S層面的的后臺進(jìn)程、檢查點(diǎn)以及WAL或者文件寫的FSYNC都會讓OS產(chǎn)生一個抖動，從而對事務(wù)提交或者索引更新產(chǎn)生性能影響。在并發(fā)量較大、存在熱點(diǎn)寫數(shù)據(jù)的應(yīng)用中，就很可能會產(chǎn)生一定的影響了。
我們無法去改變上面所說的DOUBLE BUFFERING的問題，這只能通過國產(chǎn)數(shù)據(jù)庫廠商的努力在自己的數(shù)據(jù)庫產(chǎn)品里全面引入DIO來解決了。實(shí)際上目前為止只有Oracle能夠比較好的把控DIO，除此之外，哪怕是SQL SERVER這種老牌的商用數(shù)據(jù)庫，雖然可以支持DIO，但是也不建議啟用DIO。
可能有些朋友覺得偶爾出現(xiàn)幾條SQL執(zhí)行變慢沒啥所謂，這可能和你看到的應(yīng)用場景有關(guān)。如果是股票交易或者銀行交易出現(xiàn)了某個時段幾百筆交易延時異常，那么對于這個企業(yè)來說就是運(yùn)維事故了。如果一條核心交易的SQL，平時執(zhí)行只需要5毫秒，抖動時就可能變成三四十毫秒，現(xiàn)在網(wǎng)聯(lián)對金融機(jī)構(gòu)的交易超時監(jiān)控十分嚴(yán)格，一次這樣的抖動足以產(chǎn)生一次告警了。
要想避免此類抖動，必須在物理結(jié)構(gòu)上做好優(yōu)化。我今天提出幾點(diǎn)優(yōu)化的建議。首先是對底層存儲的優(yōu)化，如果不是使用集中式存儲，那么還需要考慮512E和4KN等現(xiàn)代磁盤扇區(qū)大小的問題以及相關(guān)的對齊問題。今天篇幅有限，就不展開討論了，有興趣的朋友可以參考我以前寫過的一篇文章《原來ADVANCED FORMAT HDD已經(jīng)普及了》（https://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647848163&idx=1&sn=0f27f69e5d337a3873d6f3cdaa841a24&chksm=88786877bf0fe161178bed2cc05c2db84265ae3356ade0847e81b2e331e299d580c89dc31c9f&token=1445168299&lang=zh_CN#rd）。
除此之外，怕抖動的核心交易系統(tǒng)盡可能使用比較快的存儲介質(zhì)，比如NVME SSD，盡可能降低平均IO延時是從根本上降低IO抖動帶來的問題的最便宜的方法，不要覺得SSD很貴，實(shí)際上在這里多花點(diǎn)錢可以在其他地方少花更多的錢。
第二個需要關(guān)注的就是存儲的規(guī)劃，通過使用獨(dú)立的表空間和文件系統(tǒng)，讓相互影響，可能導(dǎo)致運(yùn)行毛刺的應(yīng)用之間的沖突盡可能地減少。如果系統(tǒng)不重要，或者抖動無所謂，那么不需要做這方面的優(yōu)化，而如果這個系統(tǒng)是十分關(guān)鍵的核心系統(tǒng)，那么在這方面做再多的工作都是值得的。在二十多年前，搞Oracle 7的時候，這些手段我也都用過。
對于寫入十分重的系統(tǒng)，WAL盡可能獨(dú)立存儲于高性能的獨(dú)立磁盤上，避免與其他讀寫IO沖突。小型熱表也可以存儲于獨(dú)立的表空間里。相對靜態(tài)，但是會大規(guī)模掃描的冷數(shù)據(jù)獨(dú)立存儲，訪問十分頻繁的表的索引與數(shù)據(jù)分開等都是可以采取的IO隔離手段。具體要根據(jù)業(yè)務(wù)的特點(diǎn)去做規(guī)劃。前面討論的都是從本地磁盤的角度去考慮的，實(shí)際上目前大多數(shù)系統(tǒng)使用集中式存儲，很多IO延時穩(wěn)定性的問題可能要考慮后端存儲的規(guī)劃與優(yōu)化，大家要注意這個問題。后端存儲分過來的盤和實(shí)際的物理盤是不同的。
第三個需要關(guān)注的問題是OS層面針對性的優(yōu)化，這一點(diǎn)大家可以參考我的另外一篇文章《Postgresql數(shù)據(jù)庫優(yōu)化上該考慮些什么》（https://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647849429&idx=1&sn=2776253a04b780d090bfe7a03784345c&chksm=88786541bf0fec573182c704e41c0adddc9d96ee0af694cea263d685ce51fb3f9b4aa7700f52&token=1445168299&lang=zh_CN#rd），這里我就不重復(fù)介紹了。
第四個要考慮的是SHARED_BUFFERS的設(shè)置，如果我們在運(yùn)行一個十分關(guān)鍵的核心交易系統(tǒng)，那么建議還是配置大一點(diǎn)的物理內(nèi)存，并將SHARED BUFFFERS設(shè)置的足夠大，盡可能地讓熱點(diǎn)數(shù)據(jù)都能夠長期緩沖在數(shù)據(jù)庫緩沖區(qū)里，從而穩(wěn)定關(guān)鍵業(yè)務(wù)地運(yùn)行效率。但是業(yè)務(wù)系統(tǒng)十分復(fù)雜，是不是也會產(chǎn)生一些對大型冷數(shù)據(jù)的掃描操作。這些操作盡可能地放到只讀備機(jī)上去做，而不要影響核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫緩沖。一種更好的設(shè)計(jì)是將這些可能對核心交易產(chǎn)生影響的數(shù)據(jù)從核心數(shù)據(jù)庫中剝離出去，另外建個庫，那樣的話對核心交易的影響就小多了。
文章標(biāo)題：PG類數(shù)據(jù)庫優(yōu)化之穩(wěn)定關(guān)鍵SQL執(zhí)行速度
網(wǎng)站鏈接：http://www.dlmjj.cn/article/dpggpee.html
