`
muxiaolin
  • 浏览: 30451 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

新闻搜索

阅读更多
最近在做新闻频道的搜索,数据量1000W+,预计索引size在20G左右。

百万数据量下用BerkeleyDB速度提升相当明显,但是上到千万时候,性能就没那多突出了。

手机之家的设计方案网上也有,就是用的BerkeleyDB

但是不能单纯使用,本来想做全文检索,但是数据量太大,性能有点问题。尽管可以通过其他手段拆分和优化,但是借着这个机会想用用hadoop,要不然可能没有机会了。

暂时先做标题检索,等学完hadoop后看看分布式后有没有效果,速度是不是有提升。

首先实现的思路是lucene用磁盘索引,只存储ID和title,因为搜索结果页只有title

然后用BerkeleyDB做存储,存储不用 key<String>,value<Object> ,而是用<String><String>,存储都用String。因为value是多字段的,所以刚开是想用Object-XMl-String,后来想为什么不用Object-JSON-String,这样更接受空间。


大概测试了一下,400w的id和title才500M  1000w也不过1g左右,搜索应该很快。更新时也不会产生很多的零碎段文件,索引的优化也很快。

BerkeleyDB的get一条信息,大概15ms,加上转换组装成xml,100ms肯定没有问题。性能还是不错的。 BerkeleyDB存储400w占用 11G空间,1000w也就30G,对BerkeleyDB应该不是什么大问题。

也许还有很多NOSql的数据库要比BerkeleyDB好,所以换成其他的,也许吞吐量会更大。

但是目前来说,全文检索暂时还是一个障碍,等过段时间搞完hadoop,这些都应该是小菜了。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics