在時間軸上記錄數(shù)據(jù)的挑戰(zhàn)之一，就是如何針對你的使用目的，將數(shù)據(jù)量保持在可管理的范圍內(nèi)。磁盤空間確實比以前便宜多了，而且能夠存儲幾個TB的數(shù)據(jù)也沒有問題，然而，隨著數(shù)據(jù)的不斷增長，確保這些數(shù)據(jù)能夠一直可查詢和可移動(如果需要的話)，則是明智的。

有些系統(tǒng)采用高分辨率采集數(shù)據(jù)，并存入關(guān)系數(shù)據(jù)庫中。這樣做，解決了數(shù)據(jù)獨立查詢的問題，而且也能夠用SQL對這些數(shù)據(jù)做些處理，這對很多工程師來講，是一個相對直接和順手的事情。而且，因為采集的這些數(shù)據(jù)從來不會刪除，最后將得到一個相對規(guī)整的數(shù)據(jù)庫，而規(guī)整性肯定有利于數(shù)據(jù)庫的性能，而且，對于大規(guī)模數(shù)據(jù)庫來說，也能夠維持其效率。

就個人而言，用一個已成為事實標(biāo)準(zhǔn)的存儲系統(tǒng)來存儲測量數(shù)據(jù)的話，我還沒發(fā)現(xiàn)會缺少什么，這個存儲系統(tǒng)就是循環(huán)數(shù)據(jù)庫(Round Robin Database，RRD)。RRD的基本思想是，隨著時間的推移，一旦達(dá)到某個你選定的周期(小時、天、周、月、年)，則有意地降低數(shù)據(jù)的分辨率。這樣樣做的理由是，大多數(shù)測量數(shù)據(jù)只是在最近的時間周期內(nèi)有意義，而且另外一個好處就是RRD的數(shù)據(jù)文件不會增長到超過限制，這意味著你不用擔(dān)心磁盤空間的問題。



許多系統(tǒng)都有RRD的分辨率定義，即對于磁盤空間采取保守做法，從一小時開始就從最高分辨率往下降。這滿足你的要求嗎?或許滿足，也或許不滿足，取決于是什么測量數(shù)據(jù)，從哪個時間點開始使用這些數(shù)據(jù)，以及從整個應(yīng)用來說單個的測量數(shù)據(jù)有多重要。我曾經(jīng)看到有的機(jī)構(gòu)保存了若干年的、有幾千個測量指標(biāo)的、分辨率為10秒的數(shù)據(jù)，也看到其他成功的公司，他們的做法是最近一小時的分辨率是15秒，最近一天的分辨率是1分鐘，而最近一周的分辨率是5分鐘。很明顯，因為無法回到過去獲得更多細(xì)節(jié)數(shù)據(jù)，所以應(yīng)將分辨率設(shè)置為多粒度的。

高分辨率數(shù)據(jù)應(yīng)存留多長時間呢?這也是一個眾說紛紜的問題。就我個人而言，我從來不需要知道www125服務(wù)器的CPU在2005年2月10日的12:34:50和12:34:60這兩個時間點的情況，但我對2005年所有Web服務(wù)器在每周的峰值情況會很有興趣，所以我對最大值和平均值的保存時間會比原始數(shù)據(jù)的保存時間要長。像分辨率的情況一樣，如果你發(fā)現(xiàn)管理起來有問題，則數(shù)據(jù)的存留時間(retention)可以調(diào)小一點。

在決定測量的分辨率時，要想清楚它們的使用情況。你要查看這些數(shù)據(jù)以找出宕機(jī)或性能下降的原因嗎?如果是的話，你就要將分辨率設(shè)得高一點，小于一分鐘。你要將數(shù)據(jù)用于以3、6或9個月的時間尺度做容量規(guī)劃嗎?是的話，你就要將最大值和最小值的數(shù)據(jù)保存得更長一些。

還要讓這些數(shù)據(jù)幫你獲得模式的歷史意義，用這些數(shù)據(jù)回答下面的問題時，測量數(shù)據(jù)采集系統(tǒng)會真正出彩的：

● 對某個特定資源，每天的峰值時是哪些?每周周的峰值日是哪些?每年的峰值月是哪些？

● 有季節(jié)性模式嗎?如夏時日會低些，節(jié)假日會高些，峰值會出現(xiàn)在學(xué)校上課期間，等等。

● 最大(波峰)值與最小(波谷)值比較起來怎么樣？

● 在網(wǎng)站建設(shè)用戶分布于全球、跨越多個時區(qū)的情況下，波峰與波谷的關(guān)系是否發(fā)生變化？