在时光轴上记载数据的挑衅之一，就是若何针对你的应用目标，将数据量坚持在可治理的规模内。磁盘空间确切比以前廉价多了，并且可以或许存储几个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个月的时光标准做容量计划吗?是的话，你就要将最年夜值和最小值的数据保留得更长一些。

还要让这些数据帮你获得模式的汗青意义，用这些数据答复下面的问题时，测量数据采集体系会真正出彩的：

● 对某个特定资本，天天的峰值时是哪些?每周周的峰值日是哪些?每年的峰值月是哪些？

● 有季候性模式吗?如夏时日会低些，节沐日会高些，峰值会涌现在黉舍上课时代，等等。

● 最年夜(波峰)值与最小(波谷)值比拟起来怎么样？

● 在网站扶植用户散布于全球、跨越多个时区的情形下，波峰与波谷的关系是否产生变更？