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

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

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

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

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

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

對(duì)于一個(gè)數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)來(lái)說(shuō)，其優(yōu)化是從上到下的。

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

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