IT牛人博客聚合

当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇 Twitter’s New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如 新 Twitter，新搜索，我在这也就算是炒冷饭了。

twitter之前的搜索使用的是被它收购的Summize公司的技术，是基于mysql的搜索，具体技术细节不祥。 Finding A Perfect Match有提到，Summi

查看全文: http://www.udpwork.com/item/2997.html

有网友留言询问我对zoie的DocIDMapperImpl实现是否有了解。说实话，之前看zoie也只是大面上的，知道DocIDMapperImpl的用处，但没有仔细分析它的算法。就趁着夜深人静，把这个类好好琢磨了下。但我得承认，看这种伤脑筋的算法让我有些吃不消，下面就列出我对它的大致分析，如果有不恰当的地方，也望指正。

还是说下DocIDMapperImpl的作用吧。在zoie中，uid和lucene的docid有一一对应关系。从docid到uid的映射很简单，就是分配个maxdoc大小的数组，索引位置是docid，值是uid。这样做也是因为docid是从小到大自增的，大小总有限。但uid是long型的，使用数组反映射是不行了，一

查看全文: http://www.udpwork.com/item/2066.html

Zoie是LinkedIn开源的基于lucene的实时检索系统，对于它的介绍及初步使用可参考我的上一篇文章“使用Zoie构建实时检索系统”。在初步研究并理解了Zoie的源码实现后，本文分析一下Zoie的实现。

实时检索的核心原理

通常的检索系统中，建索引和查询是分开的，即建索引是离线的，新的索引会以一定频率（比如每隔5分钟）供查询端使用。对于一些站内检索来说，这种延迟性使得：不需要建索引的速度足够快（只要能跟的上提交频率就行），查询的效果不必完全精确。而要取得实时检索效果，典型的思路是：建索引和查询是在一个进程内，这样每一次的添加索引都会被下一次的查询用到，但这里面的细节还是需要好好琢磨解决的，下面就给出Zoie的基于Lucen

查看全文: http://www.udpwork.com/item/1645.html

Zoie是LinkedIn开源的实时检索系统，它本身用于LinkedIn的用户profile页检索。且不说专业的搜索引擎，大多数的站内检索基本都不是实时的，一般都会有几分钟的延迟。但LinkedIn认为，用户profile信息的检索需要实时的效果，因为如果搜索结果不正确或不理想会很影响用户体验。所以，LinkedIn的Zoie实现了秒级别的实时检索效果。Zoie在LinkedIn跑了有两年多时间，这个开源项目可以说是起点就比较成熟的，这个项目提供了较为丰富的功能和工具，除了核心的API外，它还提供了管理和监控工具、嵌入jetty的Web server demo、一些实用的DataProvider等。实现上自然是基于lucene了，也

查看全文: http://www.udpwork.com/item/1646.html