IT牛人博客聚合

前两天在solr邮件组看到一封广告帖，一个叫searchblox的搜索产品可免费使用，好奇心驱使我简单了解并使用了一下。searchblox是基于lucene的搜索解决方案，现在的版本已经是6.1,看来也有些年头了。searchblox不是个开源产品，有免费的版本，也有收费的版本，看文档介绍，收费版本除了提供服务支持还多了复制功能。

功能上看，searchblox集成了爬虫和搜索功能，也提供Http API接口供索引和查询，可以在http://www.searchblox.com/developers/documentation上更多的了解searchblox的功能。但搜索功能方面，它也就是solr的子集。试用它很简单，下载解压缩

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

问题背景

基于solr的新搜索系统已经使用了有段时间，不过之前上的几个库都很小，也没发现什么性能问题。最近上了thread和post库后，性能问题显现出来。这段时间解决的性能问题有好几个，本文只着重于SolrIndexSearcher的search问题。thread库索引大小有400M多，记录数有400多万，原来的基于lucene的系统的查询处理耗时一般在10-30ms，而同样的请求，新系统耗时在50-100ms。而post库索引大小有6G多，记录数有3000多万，旧系统的查询处理时间一般在30-80ms，而新系统往往需要400-800ms，性能差距还是很明显的。

因为SolrIndexSearcher是基于lucene的Ind

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

当习惯于粗略浏览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

在上一文《solr ReplicationHandler使用介绍》的基础上，本文接着对solr的ReplicationHandler实现细节做些分析，这个分析原则上没有摘取大段代码，窃以为摘了代码后未见得有很好的阐述效果，但不摘取后窃又发现，阐述的效果依旧不好。归结起来，还是窃的表达不够深入浅出所致。闲言少叙，直接上内容。

1、master的工作

对于ReplicationHandler的复制功能来说，核心的问题确定是在一个时间点要复制哪些文件，这就用上了lucene的IndexDeletionPolicy的特性。lucene在初始化时，会调用IndexDeletionPolicy.onInit(List<? exten

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

solr1.4中引入ReplicationHandler代替外部脚本来复制索引数据，ReplicationHandler使得复制索引数据更自动化。对于使用者来说，只要简单的配置好，就可以一劳永逸的享受solr的复制功能了。下面介绍其使用相关内容。

1、配置

ReplicationHandler是个RequestHandler，如果需要使用它，也就是在solrconfig.xml中配置它，下面介绍ReplicationHandler的配置参数。

1.1、Master

master的配置示例如下：

<requestHandler name="/replication" class="so

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

项（Terms）

Term分为两种，单个词或者词组，词组需要包括在双引号中。

域(Fields)

当需要在指定的field内搜索term时，可以用诸如[field_name]:[term]的形式搜索，如不指定field，则在默认的field中搜索，例如：

title:”The Right Way” AND text:go

注意：在指定field中搜索词组需要加双引号，否则认为只在指定field中搜索第一个term在默认的field中搜索其他的term

通配符搜索

匹配单个字母使用?做通配符，匹配0个或多个字母使用*做通配符。

模糊搜索

Lucene的模糊搜索算法采用Levenshtein D

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

很多人在使用lucene时会使用其提供的queryparser分析query。不过，lucene的queryparser从一开始到现在都没有充分考虑中文等语言的特点，使得查询中文会出现让人不可理解的查不到结果的情况。这个bug就是LUCENE-2458 。

这个问题简单说来就是，对于一个连续的中文query，queryparser将Analyzer返回的Term序列构成了PhraseQuery（也有可能是MultiPhraseQuery），而PhraseQuery默认的匹配规则是要求Term序列在索引的文档中完全顺序匹配。这对于英文查询来说是可以接受的，因为queryparser在分析query时，首先通过AND、OR、NOT将q

查看全文: http://www.udpwork.com/item/2009.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

对于中文搜索引擎来说, 中文分词是整个系统最基础的部分之一, 因为目前基于单字的中文搜索算法并不是太好. 当然, 本文不是要对中文搜索引擎做研究, 而是分享如果用 PHP 做一个站内搜索引擎. 本文是这个系统中的一篇.

我使用的分词工具是中科院计算所的开源版本的 ICTCLAS. 另外还有开源的 Bamboo, 我随后也会对该工具进行调研.

从 ICTCLAS 出发是个不错的选择, 因为其算法传播比较广泛, 有公开的学术文档, 并且编译简单, 库依赖少. 但目前只提供了 C/C++, Java 和 C# 版本的代码, 并没有 PHP 版本的代码. 怎么办呢? 也许可以学习它的 C/C++ 源码和学术文档中, 然后再开发一个 PH

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