大量较为频繁读写的文件一般如何进行存储？

Question

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

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

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

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

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

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

Answer 1

文件内容当然不能存在关系型数据库里。但是你可以把文件的元数据比如原始的文件名，创建者，描述，关键字等，以及文件实际存储信息存在数据库，方便查询。
如果数据量不是很大（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键就可以快速的把文件读出来。如果要更新（我这里没有这个应用场景），只需把旧的元数据标记为失效，插入新的元数据。定期整理文件即可。

Answer 2

GridFS