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中存储长字符串后的后遗症,我基本已经放弃在数据库中存储长字符串了,我现在更加偏向于使用文件系统存储这些小说。