`
imjl
  • 浏览: 156317 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

无聊猜想:高并发,更新要求高的解决思路

阅读更多
一般网站(假设用 Lucene )要做更新频率比较高的,常见的是大小索引包,大的索引包是旧数据索引,小索引包是新数据索引。更新主要集中在小索引包这里,因为索引小,所以完成索引到能提供搜索的时间是比较短。

但是有时候也不能满足一些高并发的网站高更新需求,高更新要求指的是:用户可能提交了信息后,希望提交后,就能搜索到。这个用lucene的可能就有点吃力。这类一般修改的也很多。

这样可能就需要考虑自建,于是就需要考虑以下几个因素:

1:索引:索引通常是倒排,一个termid最多包含多少个docid呢?以新索引来看应该不会多的很,如果很多,那么可以定期写一个索引,顶多到时候并发到三个地方(旧索引(磁盘),新索引(很新,还在内存),新索引(旧,写到磁盘))搜索。

2:锁:降低锁的粒度,比如建立多个termid的锁。

3:排序:一般是按照score和时间,score可以在最小化范围后进行积分计算,比如归并,快排等。时间就有点麻烦,假如只是时间递增排序或者递减排序,那么就是做个按照时间排的堆索引,但是如果还提供某个时间段,那就需要按照时间段(比如分,比如秒来排序),如果很复杂还要设计时间排序索引的结构,比如用AVL,RB树等。

4:操作:建立独立的更新和删除结构。

5:定时更新到磁盘。


以上未经实证,只是本人无聊猜想。如有雷同,纯属巧合。

欢迎拍砖,人身攻击免了。



分享到:
评论
1 楼 strayly 2010-05-19  
可以试试zoid,LinkedIn开源的实时检索系统 基于lucene
http://strayly.iteye.com/blog/669143

相关推荐

Global site tag (gtag.js) - Google Analytics