把數(shù)據(jù)庫該干的活交給OS可行嗎

權(quán)露

這兩天在思考一個問題，現(xiàn)在的OS越來越強大了，能不能把一些數(shù)據(jù)庫該干的事情交給OS去做，這樣數(shù)據(jù)庫的內(nèi)核可以大大簡化。這個觀點讓我想起了10多年前Linux是否需要提供o_direct這個文件IO選項給開發(fā)者的討論。當(dāng)時Linus Torvalds說了那句十分著名的話—“In short，the whole‘lets bypass the OSnotion is just fundamentally broken. It sounds simple，but it sounds simple only to an idiot who writes databases and doesnt even UNDERSTAND what an OS is meant to do”。他甚至認(rèn)為繞過OS強大的VMM設(shè)計去處理IO是傻瓜才會干的事情，因為Linux已經(jīng)為數(shù)據(jù)庫類的應(yīng)用提供了強大的能力。

實際上早期的數(shù)據(jù)庫也是十分依賴于操作系統(tǒng)的，本人使用過的第一個數(shù)據(jù)庫RMS就是一個基于openVMS的記錄管理系統(tǒng)，其底層依賴于操作系統(tǒng)的基礎(chǔ)IPC能力構(gòu)建。后來隨著數(shù)據(jù)庫變得越來越復(fù)雜，需要支持的底層OS平臺越來越多，數(shù)據(jù)庫產(chǎn)品逐漸把一些以前OS干的事情由自己獨立來干。2012年的一次測試，讓我對數(shù)據(jù)庫與OS融合后的能力有了深刻的體會。當(dāng)時在一臺Oracle公司的T4-8上，服務(wù)器+Solaris操作系統(tǒng)+Oracle 11g的組合跑出了驚人的高性能。不用做復(fù)雜的調(diào)優(yōu)，僅僅裝好數(shù)據(jù)庫，簡單調(diào)整一下數(shù)據(jù)庫參數(shù)，就取得了那次測試最佳的成績。后來和參加測試的其他人聊了聊，他說在這個組合里，Oracle的一些并發(fā)控制相關(guān)底層調(diào)用得到了全面優(yōu)化，操作系統(tǒng)幫助Oracle的閂鎖與鎖操作的并發(fā)能力得到了極大地提升。

實際上開頭提的問題應(yīng)該不是問題了，現(xiàn)在的Linux與90年代剛剛進入我們視野的時候已經(jīng)不可同日而語了，那時候的Linux可以很好地支撐Web應(yīng)用，但是對數(shù)據(jù)庫的底層支持還比較弱。而現(xiàn)在Linux的能力已經(jīng)得到了巨大的強化，無論是Redis，MongoDB還是ClickHose，這些新生代的數(shù)據(jù)庫產(chǎn)品無一例外的充分利用了操作系統(tǒng)底層的能力，從而簡化了很多傳統(tǒng)數(shù)據(jù)庫自己要做的復(fù)雜控制。外加在存儲引擎上使用了大量的開源技術(shù)，使得數(shù)據(jù)庫研發(fā)的門檻大大降低了。包括我們耳熟能詳?shù)拈_源數(shù)據(jù)庫MySQL，Postgresql，它們在存儲引擎上也充分利用了操作系統(tǒng)的能力。充分利用OS FILE CACHE的能力來緩沖數(shù)據(jù)，從而提升IO性能，通過使用帶日志的文件系統(tǒng)來消除數(shù)據(jù)庫double write的開銷，這一切都是數(shù)據(jù)庫向OS能力借力的有效例證。

不過通用關(guān)系型數(shù)據(jù)庫面臨的場景十分復(fù)雜，在某些特殊的高負(fù)載場景下，OS的自動優(yōu)化能力還是無法滿足數(shù)據(jù)庫的需求。2007年引發(fā)的關(guān)于o_direct的討論就是一個十分典型的例證，當(dāng)時數(shù)據(jù)庫廠商需要自己來控制IO，而不是使用OS提供的能力。

在一個DBA的眼里，Linus的言論似乎是有些武斷了，針對復(fù)雜的通用關(guān)系型數(shù)據(jù)庫來說，數(shù)據(jù)庫自己管理自己的緩沖，在有些時候比完全依賴于OS提供的文件緩沖能力，要高效的多。數(shù)據(jù)庫有自己的一些更為復(fù)雜的判斷熱數(shù)據(jù)的方法，因此在shared buffer中合適AGEOUT頁面，清理哪些頁面，數(shù)據(jù)庫管理系統(tǒng)可能更清楚。

不過對于大多數(shù)業(yè)務(wù)應(yīng)用來說，OS提供的FILE CACHE已經(jīng)能夠很好地幫助我們提升性能了。在目前的Postgresql的官方文檔中，還是建議shared buffer只使用20 % ～30 %，剩下的內(nèi)存交給OS。有些PG用戶認(rèn)為這個建議十分好，他們的數(shù)據(jù)庫按照這個建議設(shè)置后性能十分穩(wěn)定。不過也有些用戶認(rèn)為把物理內(nèi)存盡可能交給shared buffer會具有更好的性能。這是因為業(yè)務(wù)應(yīng)用場景的復(fù)雜性，導(dǎo)致2種策略可能在某些場景下會出現(xiàn)相反的效果。

對于一個數(shù)據(jù)庫應(yīng)用系統(tǒng)來說，其優(yōu)化是從上到下的。對于一個復(fù)雜的應(yīng)用系統(tǒng)來說，越往上的優(yōu)化器效果就越好，只不過越往上的優(yōu)化對于前期建設(shè)隊伍的能力要求也越高，前期的投入也越大。對于一些較小的，不太復(fù)雜的應(yīng)用系統(tǒng)來說，只需要從下層做好優(yōu)化就可以了，其實施成本也很低，而負(fù)載越高，越復(fù)雜的系統(tǒng)就越需要更上層的優(yōu)化。對于有些系統(tǒng)來說，僅僅依賴操作系統(tǒng)提供的優(yōu)化能力就不足夠了。就像是開手動擋的車和自動擋的車，在一般路況下，自動擋車就足夠用了，但是在一些特殊的戶外陡坡上，手動擋車可能更勝任，自動擋車完全不勝任。因為自動化的處理能力還是有限的。

不過隨著操作系統(tǒng)的不斷發(fā)展，其能力也越來越強，操作系統(tǒng)對數(shù)據(jù)庫的支撐能力也在不斷增強。有些以前需要依靠數(shù)據(jù)庫核心代碼去優(yōu)化的工作依然可以由操作系統(tǒng)來承擔(dān)。一些專用場景的數(shù)據(jù)庫產(chǎn)品會首先從中受益，有時候數(shù)據(jù)庫不用做升級，升級一下OS，數(shù)據(jù)庫性能自然就提升了。針對某種數(shù)據(jù)庫去定制與優(yōu)化操作系統(tǒng)也是一種思路，在一些云原生的數(shù)據(jù)庫或者公有云RDS上，可能更容易實現(xiàn)。