对于预警而言，主要是运行的性能指标与动态阈值的比较，所以提高动态基线平滑度，减少毛刺，便使基线更能与业务行为拟合，提高阈值准确性，降低误报。

提高历史数据的访问效率，简单来看。有两个角度：一个就是减小数据量，这个要依据业务数据的“生命期”进行按期自动归档，这样可以减少检索集，从而提高检索效率；再者就是充分利用分层存储的技术，将热点数据分布在性能更好的tier，从而提高检索效率。另外分布式的架构也可以很好的在节...

数据的价值肯定是业务说了算，所以历史数据的归档肯定也是业务进行的，无论是通过数据库级的存储过程或者是定制脚本完成数据转储等等手段，都是业务人员指定数据的“时间戳”。而后端架构层也不是“看热闹”就行了，在海量数据的存储上，肯定存储典型的热点和非热点也就是冷热数据...

大数据代表了当前的一个趋势  在解决这种问题的时候确实有很多自己的优点关于规模，我感觉还是得看架构，如果可以根据规模的增长，可以做到性能和容量的线形扩展，就是非常可取的。 初期只能估算一个差不多的值，后期再慢慢扩展和完善...

db2有online backup tablespace

备份速度是多少，全库备份时间是多少，走的是局域网、lanfree、还是光纤。当前历史数据是否单独存放于独立表空间。

若有数据库全库备份，和该时间之后的归档日志（保证归档可用，不存在数据页损害），可是完全恢复。但是要知道数据库备份的目的是为了数据的恢复。为了更快的恢复数据减少业务停止时间。一次备份，前滚归档日志，理论上是可行，在库小，访问量小的情况下可是延长做备份操作时间。当库较大，归...

这个问题比较大，数据的备份设计主要从业务的需求展开，包括备份内容、备份数据量、备份频率和保留周期以及备份窗口等，根据不同的要求采用不同的架构，如走lan的，lan free的等等，同时考虑采用消重等技术的使用...

有些是文件型的历史数据，如一些报表数据或者是数据库装载的输入数据等，也有数据生命周期管理的诉求

根据我的经验，民航的旅客信息一般保留10年，数据量也是爆发是增长，如果我是架构师，我会规划分布式存储来处理类似问题，类似于oracle exadata的storage index技术，按照时间或特定字段进行数据分布式处理，将计算处理过程与IO运算过程分开，这样才可能保证性能。同时，横向扩展能力也可...