我们之前见过一个这种情况的架构，采用“逻辑统一、物理分散”的建设思路1.统一访问入口：在统一访问入口处根据客户端提交的应用程序信息返回客户端后续和哪个存储入口进行访问；2.各地建立缓存：由于非结构化数据一般比较大，我们建立一个缓存服务器功能，比如业务上传时，将数据保存...

如果仅仅是备份速度的问题，可以利用存储本身的卷快照技术，比如NETAPP的snap mirror.如果是解决频繁查询和备份的问题，我觉得可以尝试NOSQL数据库存储方式，例如MongoDB

既然没有用，那么二次挖掘的目的是什么呢？如果完全没有用，那么就可以离线归档了。放到磁带、光介质存储上或者其他归档存储。

海量数据可以考虑对象存储方式

还是得看我们采用什么样的解决方案。如果单纯的存储分层，那么只能通过主动的方式对数据进行删除。如果采用了相关的解决方案，可以通过策略做删除，比如基于tsm的备份归档，备份通过那四个参数来做，归档通过保留周期来做，超过参数的设置后，数据会被自动删除。...

这个确实更偏向管理问题，但是作为技术，既然摊上了，就尽量在自己的职责范围内解决一些，毕竟梳理通顺了自己后期也省事。做好基线文档，梳理系统，之前的可以乱，但最起码从自己接管开始，后续的上线和下线要有序进行下线没用的库，可以倒着做，通过对现有上层应用的了解或对数据库连接的分...

伟光的图非常不错个人认为gpfs更偏向在线数据处理 hsm一般用在和备份方案集成的分层存储 ltfs还没做过相关的项目，根据我的了解，主要特长为基于磁带的文件系统 但是企业版的ltfs已经是解决方案类型的产品了而且，正如楼上的图中所示，IBM实际上已经打通了这些产品，集成的解决...

我们的经验是数据服务于业务，数据分类要业务优先1.先对数据进行业务属性归类，比如每个业务的交易量和交易数据等各不相同2.先后对同一业务内的数据进行周期分类和管理，比如每个业务内部的热数据周期可能就不一样；虽然1和2的分类不同，但是可以抽象出相同的声明周期管理模式，然后...

数据本身是具备生命周期的特性的，其原理为：随着时间的积累，数据访问频次变化和数据量累积变化成反比。对数据根据访问频次进行数据价值评估，然后再对大量低价值的数据采取低成本保存手段，使得数据价值和存储技术与管理相匹配，进而大幅度降低整体数据存储成本。针对上面的情况，不...

先谈一点自己的看法，抛砖引玉不管什么类型的数据，基本上都具备生命周期的特性。前些年企业对数据的管理是相对比较粗放的，因为数据量比较小，业务规模也比较简单，不管怎么管理和使用，都没有太大的压力。近几年随着IT信息化的推进，不管是企业的业务系统还是数据量都有了一个非常爆...