在時間軸上記錄數據的挑戰之一，就是如何針對你的使用目的，將數據量保持在可管理的范圍內。磁盤空間確實比以前便宜多了，而且能夠存儲幾個TB的數據也沒有問題，然而，隨著數據的不斷增長，確保這些數據能夠一直可查詢和可移動(如果需要的話)，則是明智的。
有些系統采用高分辨率采集數據，并存入關系數據庫中。這樣做，解決了數據獨立查詢的問題，而且也能夠用SQL對這些數據做些處理，這對很多工程師來講，是一個相對直接和順手的事情。而且，因為采集的這些數據從來不會刪除，最后將得到一個相對規整的數據庫，而規整性肯定有利于數據庫的性能，而且，對于大規模數據庫來說，也能夠維持其效率。
就個人而言，用一個已成為事實標準的存儲系統來存儲測量數據的話，我還沒發現會缺少什么，這個存儲系統就是循環數據庫(RoundRobinDatabase，RRD)。RRD的基本思想是，隨著時間的推移，一旦達到某個你選定的周期(小時、天、周、月、年)，則有意地降低數據的分辨率。這樣樣做的理由是，大多數測量數據只是在最近的時間周期內有意義，而且另外一個好處就是RRD的數據文件不會增長到超過限制，這意味著你不用擔心磁盤空間的問題。

許多系統都有RRD的分辨率定義，即對于磁盤空間采取保守做法，從一小時開始就從高分辨率往下降。這滿足你的要求嗎?或許滿足，也或許不滿足，取決于是什么測量數據，從哪個時間點開始使用這些數據，以及從整個應用來說單個的測量數據有多重要。我曾經看到有的機構保存了若干年的、有幾千個測量指標的、分辨率為10秒的數據，也看到其他成功的公司，他們的做法是最近一小時的分辨率是15秒，最近一天的分辨率是1分鐘，而最近一周的分辨率是5分鐘。很明顯，因為無法回到過去獲得更多細節數據，所以應將分辨率設置為多粒度的。
高分辨率數據應存留多長時間呢?這也是一個眾說紛紜的問題。就我個人而言，我從來不需要知道www125服務器的CPU在2005年2月10日的12:34:50和12:34:60這兩個時間點的情況，但我對2005年所有Web服務器在每周的峰值情況會很有興趣，所以我對大值和平均值的保存時間會比原始數據的保存時間要長。像分辨率的情況一樣，如果你發現管理起來有問題，則數據的存留時間(retention)可以調小一點。
在決定測量的分辨率時，要想清楚它們的使用情況。你要查看這些數據以找出宕機或性能下降的原因嗎?如果是的話，你就要將分辨率設得高一點，小于一分鐘。你要將數據用于以3、6或9個月的時間尺度做容量規劃嗎?是的話，你就要將大值和最小值的數據保存得更長一些。
還要讓這些數據幫你獲得模式的歷史意義，用這些數據回答下面的問題時，測量數據采集系統會真正出彩的：
● 對某個特定資源，每天的峰值時是哪些?每周周的峰值日是哪些?每年的峰值月是哪些？
● 有季節性模式嗎?如夏時日會低些，節假日會高些，峰值會出現在學校上課期間，等等。
● 大(波峰)值與最小(波谷)值比較起來怎么樣？
● 在網站建設用戶分布于全球、跨越多個時區的情況下，波峰與波谷的關系是否發生變化？

本文題目：網站時間分辨率和存留時間的考慮
URL標題：http://m.newbst.com/news4/147454.html

成都網站建設公司_創新互聯，為您提供網站內鏈、Google、移動網站建設、微信公眾號、品牌網站設計、云服務器

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯