db2有online backup tablespace

个人认为：备份速度、支持的备份模式、支持的备份类型（OS、数据库、文件目录等）、扩展性等方面比较重要。

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

自动分层是根据IO的性能特点执行分层的，正好可以解决生产和历史在一起的情况，不过在定义分层策略时，要选择生产时段的性能数据，避免将历史数据迁移到SSD上。

可以写存储过程，将业务指定时间前的历史数据进行转储，也就是将历史数据和在线数据进行物理上的分离，这样一方面可以提高生产系统的查询性能，另一方面，备份的数据量也小了。

首先看业务有无此需求，我们有的系统要异地保存3年的历史数据，这个我们都是将历史数据定期归档后，然后从存储级做异地的定期传输。

网上处理zabbix分区的文章挺多的，如下你可以参考下；https://www.zabbix.org/wiki/Docs/howto/mysql_partitionhttp://blog.51cto.com/beyondhf/1887371

实时数仓的数据粒度应该要跟技术实现有关，我理解有起码有两类实现方式，一类存储指标等汇总数据，另一类是存储清洗后原始数据：1.一类是基于根据实时采集的数据，在历史存储的指标基础上行加工新的指标值。这种实现方式是没有存放实时采集的数据，存储和使用的都是指标。这样做的好...

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

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