twitter要存档tweet采用lucene做全量指数,新发型是实时索引推文。检索实时(10在几秒钟内指数)。实时索引和检索系统，称为EarlyBird。
感觉写更清晰，简洁，这个信息是真实的，只有可信足够，完全能够做到实现参考。
我只是做了一些记录:
1)基于lucene + java,michael busch是lucene committer
2)词典直接用哈希表，因此不支持term的prefix,偏序查询,哈希表使用开放链址法实现,避免大量小对象gc开销
3)postings列表在optimize之前直接用数组,依照docid生序不压缩，因此查找能够直接二分查找不须要跳跃表结构.posting增长时分配空间以block为单位,分配空间按指数预留空间
4)12个segment11个是read-only,仅仅有一个是可读可写的,一个segment中tweet数量超过8.4m时,segment经过optimize(不是lucene中的段合并。而是做压缩)变为read only.
5)11个仅仅读段并发读不须要锁。唯一的可读可写段使用volatilekeyword实现高效同步(jvm memory barrier)
http://www-users.cs.umn.edu/~gade/earlybird.pdf
感觉写更清晰，简洁，这个信息是真实的，只有可信足够，完全能够做到实现参考。
我只是做了一些记录:
1)基于lucene + java,michael busch是lucene committer
2)词典直接用哈希表，因此不支持term的prefix,偏序查询,哈希表使用开放链址法实现,避免大量小对象gc开销
3)postings列表在optimize之前直接用数组,依照docid生序不压缩，因此查找能够直接二分查找不须要跳跃表结构.posting增长时分配空间以block为单位,分配空间按指数预留空间
4)12个segment11个是read-only,仅仅有一个是可读可写的,一个segment中tweet数量超过8.4m时,segment经过optimize(不是lucene中的段合并。而是做压缩)变为read only.
5)11个仅仅读段并发读不须要锁。唯一的可读可写段使用volatilekeyword实现高效同步(jvm memory barrier)
个人感觉,twitter全量和增量分开的设计,全量能够仅仅有删除操作,禁止段合并,避免了段合并的问题,new generation和old generation的大小能够在整个执行阶段保持稳定，有利于系统性能的平稳高效。
http://www-users.cs.umn.edu/~gade/earlybird.pdf
版权声明：本文博主原创文章。博客，未经同意不得转载。