无聊猜想：高并发，更新要求高的解决思路 lucene数据结构Blog

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

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

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

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

2：锁：降低锁的粒度，比如建立多个termid的锁。

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

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

5：定时更新到磁盘。


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

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