HDFS和GridFS的比较

Hadoop出来已经很多年了，以前也有想法去学习一下，不过确实那时由于自己的眼界和所处业务环境，确实没有什么场景可以用到hadoop，学习hadoop的计划也就一直搁浅了。

最近打算做一个小说情感分析的程序，刚开始想的很简单，就是将小说下载下来，然后找开源框架进行分析即可。当我把爬虫写好了并找了一个网站进行爬取小说后发现，扒下来的文档结构非常混乱，而且后来简单的分词信息都难以保存。于是我想到了我最熟悉的NoSQL数据库——MongoDB，哈哈，我以为这下终于解决问题了，哪知道事情没有想象的那么简单。

我在某小说站点爬取了10W+小说，查看了一下mongoDB中数据集合的空间占用居然达到了140G，对于一台陈旧的老台式机来说，使用mongoDB在这么大的数据中查询是一个极度消耗时间的事儿。我当时的存储方式是将小说分块的方式存储在同一个collection中，整个collection的大小达到了380W条，每一条数据的中大概存储有1w字左右。最开始我从这个集合中查询一条数据的时间需要消耗10分钟以上，到后来我不断用程序随机查询，查询时间差不多稳定到了三到五分钟。如果需要对一个字段创建索引，那我可以先把命令输入进去，然后去吃饭，吃完后差不多就快要好了。这才仅仅10W部小说的源数据，就这么恼火，让我不敢想象后面我需要对每一本小说进行分词，创建Ngram，创建马尔科夫模型等分析时还会产生多么庞大的数据量，一个简单的单节点的mongoDB已经无法满足我对数据存储的要求了。于是，我开始思考如何优化数据存储，使数据更加安全，读写更加快捷。

就单节点服务器而言，优化数据存储的方式就是使用RAID阵列，使用RAID阵列可以将单机存储性能提升到极限。对于多节点服务器来说，也就是分布式系统的存储优化那就得依靠分布式的文件系统，分布式文件系统可以在单节点极限的情况下继续优化，而且几乎是一种可以无限扩展的方式。我最开始想到的是HBase和mongoDB，这两个NoSQL数据库有着不同的适合场景。我所知道的最直接的场景就是：HBase适合写多于读的场景，而MongoDB则适合读多于写的场景。然而经过上面的在mongoDB中存储长字符串后的后遗症，我基本已经放弃在数据库中存储长字符串了，我现在更加偏向于使用文件系统存储这些小说。