现有系统中有150G容量的非结构化数据,但备份和管理都很慢,请问有什么办法来管理和优化吗?

我们现在有一套系统中有很多非结构化的数据,都是非常细小的文档。由自己开发的公文管理系统中产生。公文没经过一道批复。就生成一个新的文档。现在的量还,没有达到海量,但150G左右的容量,文件数非常多。对这些文件进行备份,管理的时候都很慢。对于这种情况。有什么解决办法来...显示全部

我们现在有一套系统中有很多非结构化的数据,都是非常细小的文档。由自己开发的公文管理系统中产生。公文没经过一道批复。就生成一个新的文档。现在的量还,没有达到海量,但150G左右的容量,文件数非常多。对这些文件进行备份,管理的时候都很慢。对于这种情况。有什么解决办法来管理和优化吗

收起
参与13

查看其它 2 个回答qq373793057的回答

qq373793057qq373793057课题专家组系统工程师某银行

海量小文件的备份和管理处理起来确实比较麻烦,目前针对非结构化数据所用的文件系统、分布式文件系统和对象存储系统,在数据布局、条带设计、缓存管理等实现策略上都是侧重大文件的。
建议利用文件系统的扩展接口将系统大量的小文件合并成大文件后再导入文件系统集群中。小文件单独存储会形成外部和内部碎片,而合并存储后存储碎片会大大降低,能极大提高了小文件存储效率。尽量将可能连续访问的小文件在大文件中进行连续存储,这直接降低了磁盘上随机I/O比率。

银行 · 2017-06-28
浏览2445
  • 请问你说的这种小文件合并是指怎样的概念呢?。我现在管理的是海量的WORD文档。比如一个审批流程,在一个文件上会由很多人批阅,就会产生很多个有小改动的文件,但是又没办法把文件合并或者归档。所以才产生了很多的文件。
    2017-06-28
  • 之前做过的一个小文件合并,底层架构采用的是Hadoop,小文件合并是采用Hadoop支持的Sequence File文件格式。 在存储结构上,Sequence File主要由一个Header后跟多条Record组成。每个Record由一系列的二进制key/value组成。我们的文件合并实现中,将key作为小文件名,value作为文件内容。 合并文件后Hadoop 集群中写入的过程主要通过Hadoop提供的API完成。
    2017-06-28

回答者

qq373793057
系统工程师某银行
擅长领域: 存储灾备分布式系统

qq373793057 最近回答过的问题

回答状态

  • 发布时间:2017-06-28
  • 关注会员:4 人
  • 回答浏览:2445
  • X社区推广