最近在做新闻频道的搜索,数据量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,这些都应该是小菜了。
百万数据量下用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,这些都应该是小菜了。