www.999yzc.com大量较为频繁读写的文件一般如何进行存储?

( www.999yzc.com )

请问各位大神,小弟想请教一种业务场景的技术处理情况。

有大量的pdf文件需要进行存储,大家一般都是如何进行存储的?

这些文件有可能会需要写入(比如pdf做个签名上去)和下载,但不是特别频繁,但也不能排除会经常下载的可能。

存mysql应该是不合适,我记得之前看过一个文章讲文件(比如文档、图片什么的)一定不能存在关系型数据库里。

那样的读写可能会很慢,效率非常低下。

各位大神,给提供一些好的建议吧,比如像百度文库那样的平台,他们的文档都是存在什么地方的?

文件内容当然不能存在关系型数据库里。但是你可以把文件的元数据比如原始的文件名,创建者,描述,关键字等,以及文件实际存储信息存在数据库,方便查询。
如果数据量不是很大(G级别以下),文件不是特别零碎,可以直接存在硬盘上。
但是如果数据量已经/可能超过T级别,或者文件小且零碎,建议还是放在HDFS等分布式文件系统上。

我存储爬虫的html以及图片数据,是通过HDFS的MapFile格式存储的。MapFile是个已排序的键值对文件格式,我的键采用的是url的hash+采集时间,值就是文件内容。并且封装了原生的MapFile.Reader实现了读取和一定程度的缓存(目前只用了LRU)。

在HDFS提倡一次写入,多次读取的前提下,文件的更新只能是通过失效旧,使用新的策略。即把旧的元数据标记为失效,插入新的元数据,并把更新的文件写入HDFS。读取是通过新的元数据定位到文件。同时,要定期的清除已失效的文件,即把未失效的元数据读出来,将对应的文件写到新的MapFile,删除旧的MapFile,即可实现物理删除。

当然还可以使用HBase。HBase是面向列的,二进制存储的,可横向拓展的NoSQL。可以把不大于64M的数据作为单元格数据直接写进去。但是有一定的学习成本,而且对集群的硬件要求比较高。


如果数据量很大,可以上HDFS以及其他分布式文件系统,例如淘宝的TFS(开源了但是文档超少)等。不大就直接存在硬盘上。
关系型数据库可以用来存文件的元数据,比如原始的文件名,创建者,描述,关键字等,以及在实际存储的相关信息。
例如我通过HDFS的MapFile文件格式存储海量的html文件以及图片,通过文件路径(hdfs://xxxx)加上对应的hash键就可以快速的把文件读出来。如果要更新(我这里没有这个应用场景),只需把旧的元数据标记为失效,插入新的元数据。定期整理文件即可。

GridFS

(看完/读完)这篇文章有何感想! www.999yzc.com的分享…

发表评论

电子邮件地址不会被公开。 必填项已用*标注