网站时间分辨率和存留时间的考虑

发布：2018-06-18 17:40:07 浏览：3695

在时间轴上记录数据的挑战之一，就是如何针对你的使用目的，将数据量保持在可管理的范围内。磁盘空间确实比以前便宜多了，而且能够存储几个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个月的时间尺度做容量规划吗?是的话，你就要将最大值和最小值的数据保存得更长一些。

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

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

●有季节性模式吗?如夏时日会低些，节假日会高些，峰值会出现在学校上课期间，等等。

●最大(波峰)值与最小(波谷)值比较起来怎么样？

●在网站建设用户分布于全球、跨越多个时区的情况下，波峰与波谷的关系是否发生变化？