監(jiān)測(cè)數(shù)據(jù)庫的健康和行為:有哪些重要指標(biāo)?
我們沒有對(duì)數(shù)據(jù)庫討論過多少。在這個(gè)充滿監(jiān)測(cè)儀器的時(shí)代,我們監(jiān)測(cè)我們的應(yīng)用程序、基礎(chǔ)設(shè)施、甚至我們的用戶,但有時(shí)忘記我們的數(shù)據(jù)庫也值得被監(jiān)測(cè)。這很大程度是因?yàn)閿?shù)據(jù)庫表現(xiàn)的很好,以至于我們單純地信任它能把任務(wù)完成的很好。信任固然重要,但能夠證明它的表現(xiàn)確實(shí)如我們所期待的那樣就更好了。
為什么監(jiān)測(cè)你的數(shù)據(jù)庫?
監(jiān)測(cè)數(shù)據(jù)庫的原因有很多,其中大多數(shù)原因與監(jiān)測(cè)系統(tǒng)的任何其他部分的原因相同:了解應(yīng)用程序的各個(gè)組件中發(fā)生的什么,會(huì)讓你成為更了解情況的,能夠做出明智決策的開發(fā)人員。
更具體地說,數(shù)據(jù)庫是系統(tǒng)健康和行為的重要標(biāo)志。數(shù)據(jù)庫中的異常行為能夠指出應(yīng)用程序中出現(xiàn)問題的區(qū)域。另外,當(dāng)應(yīng)用程序中有異常行為時(shí),你可以利用數(shù)據(jù)庫的指標(biāo)來迅速完成排除故障的過程。
問題
最輕微的調(diào)查揭示了監(jiān)測(cè)數(shù)據(jù)庫的一個(gè)問題:數(shù)據(jù)庫有很多指標(biāo)。說“很多”只是輕描淡寫,如果你是史高治(LCTT 譯注:史高治,唐老鴨的舅舅,以一毛不拔著稱),你不會(huì)放過任何一個(gè)可用的指標(biāo)。如果這是摔角狂熱 比賽,那么指標(biāo)就是折疊椅。監(jiān)測(cè)所有指標(biāo)似乎并不實(shí)用,那么你如何決定要監(jiān)測(cè)哪些指標(biāo)?
解決方案
開始監(jiān)測(cè)數(shù)據(jù)庫的***方式是認(rèn)識(shí)一些基礎(chǔ)的數(shù)據(jù)庫指標(biāo)。這些指標(biāo)為理解數(shù)據(jù)庫的行為創(chuàng)造了良好的開端。
吞吐量:數(shù)據(jù)庫做了多少?
開始檢測(cè)數(shù)據(jù)庫的***方法是跟蹤它所接到請(qǐng)求的數(shù)量。我們對(duì)數(shù)據(jù)庫有較高期望;期望它能穩(wěn)定的存儲(chǔ)數(shù)據(jù),并處理我們拋給它的所有查詢,這些查詢可能是一天一次大規(guī)模查詢,或者是來自用戶一天到晚的數(shù)百萬次查詢。吞吐量可以告訴我們數(shù)據(jù)庫是否如我們期望的那樣工作。
你也可以將請(qǐng)求按照類型(讀、寫、服務(wù)器端、客戶端等)分組,以開始分析流量。
執(zhí)行時(shí)間:數(shù)據(jù)庫完成工作需要多長時(shí)間?
這個(gè)指標(biāo)看起來很明顯,但往往被忽視了。你不僅想知道數(shù)據(jù)庫收到了多少請(qǐng)求,還想知道數(shù)據(jù)庫在每個(gè)請(qǐng)求上花費(fèi)了多長時(shí)間。 然而,參考上下文來討論執(zhí)行時(shí)間非常重要:像 InfluxDB 這樣的時(shí)間序列數(shù)據(jù)庫中的慢與像 MySQL 這樣的關(guān)系型數(shù)據(jù)庫中的慢不一樣。InfluxDB 中的慢可能意味著毫秒,而 MySQL 的 SLOW_QUERY
變量的默認(rèn)值是 10 秒。
監(jiān)測(cè)執(zhí)行時(shí)間和提高執(zhí)行時(shí)間不一樣,所以如果你的應(yīng)用程序中有其他問題需要修復(fù),那么請(qǐng)注意在優(yōu)化上花費(fèi)時(shí)間的誘惑。
并發(fā)性:數(shù)據(jù)庫同時(shí)做了多少工作?
一旦你知道數(shù)據(jù)庫正在處理多少請(qǐng)求以及每個(gè)請(qǐng)求需要多長時(shí)間,你就需要添加一層復(fù)雜性以開始從這些指標(biāo)中獲得實(shí)際值。
如果數(shù)據(jù)庫接收到十個(gè)請(qǐng)求,并且每個(gè)請(qǐng)求需要十秒鐘來完成,那么數(shù)據(jù)庫是忙碌了 100 秒、10 秒,還是介于兩者之間?并發(fā)任務(wù)的數(shù)量改變了數(shù)據(jù)庫資源的使用方式。當(dāng)你考慮連接和線程的數(shù)量等問題時(shí),你將開始對(duì)數(shù)據(jù)庫指標(biāo)有更全面的了解。
并發(fā)性還能影響延遲,這不僅包括任務(wù)完成所需的時(shí)間(執(zhí)行時(shí)間),還包括任務(wù)在處理之前需要等待的時(shí)間。
利用率:數(shù)據(jù)庫繁忙的時(shí)間百分比是多少?
利用率是由吞吐量、執(zhí)行時(shí)間和并發(fā)性的峰值所確定的數(shù)據(jù)庫可用的頻率,或者數(shù)據(jù)庫太忙而不能響應(yīng)請(qǐng)求的頻率。
該指標(biāo)對(duì)于確定數(shù)據(jù)庫的整體健康和性能特別有用。如果只能在 80% 的時(shí)間內(nèi)響應(yīng)請(qǐng)求,則可以重新分配資源、進(jìn)行優(yōu)化工作,或者進(jìn)行更改以更接近高可用性。
好消息
監(jiān)測(cè)和分析似乎非常困難,特別是因?yàn)槲覀兇蠖鄶?shù)人不是數(shù)據(jù)庫專家,我們可能沒有時(shí)間去理解這些指標(biāo)。但好消息是,大部分的工作已經(jīng)為我們做好了。許多數(shù)據(jù)庫都有一個(gè)內(nèi)部性能數(shù)據(jù)庫(Postgres:pg_stats
、CouchDB:Runtime_Statistics
、InfluxDB:_internal
等),數(shù)據(jù)庫工程師設(shè)計(jì)該數(shù)據(jù)庫來監(jiān)測(cè)與該特定數(shù)據(jù)庫有關(guān)的指標(biāo)。你可以看到像慢速查詢的數(shù)量一樣廣泛的內(nèi)容,或者像數(shù)據(jù)庫中每個(gè)事件的平均微秒一樣詳細(xì)的內(nèi)容。
結(jié)論
數(shù)據(jù)庫創(chuàng)建了足夠的指標(biāo)以使我們需要長時(shí)間研究,雖然內(nèi)部性能數(shù)據(jù)庫充滿了有用的信息,但并不總是使你清楚應(yīng)該關(guān)注哪些指標(biāo)。從吞吐量、執(zhí)行時(shí)間、并發(fā)性和利用率開始,它們?yōu)槟闾峁┝俗銐虻男畔?,使你可以開始了解你的數(shù)據(jù)庫中的情況。
你在監(jiān)視你的數(shù)據(jù)庫嗎?你發(fā)現(xiàn)哪些指標(biāo)有用?告訴我吧!