Lucene in action 笔记 case study
一. Nutch
作为用lucene实现的开源search engine怎么使用lucene的了.
Nutch用了许多个的lucene indexes放在不同的server上, 因为是面对Web-scale的, document数目在1-10billion量级, 非常的多, 必须用许多机器同时去进行index和search操作. 而且在query的时候需要快速反应, 不能因为某个server crash了而影响正常的query.
Nutch的query architecture是相当简单的, 描述如下:
1. HTTP server接受到用户request.有个叫Query Handler的servlet来处理这个request, 并返回结果页面给用户.
2. Query Handler先对这个request做一些处理(parse request,转化为search terms), 然后forward这个query的search terms给Index Searcher machines的集群.Nutch的查询看起来要比lucene的简单的多, 就是说nutch设计了一套更简单,便于用户使用的query language, 所以这里要将Nutch query转化为具体的Lucene query.这个后面会再讨论. 每个Index Searcher并行工作, 最后返回各自的ranked list(document ids).
3. 最后有许多的search results streams返回给了Query Handler.他收集结果, 并从中找出最好的ranking list.如果有些Index Searcher超时, 没有返回结果, 就ignore他.
深入探讨一下:
前面说了Query Handler会request做些轻量级的预处理, 如去掉stop word. 然后他去并行的同时去contact 许多的Index Searcher, 实际上考虑到系统的robustness, 一个document segment会被copy到多个不同的server上, 对于每个document segment, Query Handler会随机选一个Index Searcher server来做search. 如果某个server没反应, 他会将这个server标记为unavailable, 以后就不选他了.(当然Query Handler会定时轮询各个server, 把恢复的server置成可用).
一直在说Nutch用了很多indexes, 可是Nutch按什么标准把一个huge的indexes文件, 分成很多小index了. 这个问题是在做search engine design时, 必须要回答的基本问题.
一般有两种选择, 按document分和按search term分.
比如可以把所有含有''parrot''的文档都让一个单独的Index Searcher去负责, 或把来自''http://nutch.org''的文档都让一个Index Searcher去负责. 这个只是举个例子, 分的方法有很多, 比如我一下就想到用hash.
Nutch选择了后者即Document-based segmentation, 感觉这个容易实现一点
他明显的缺点是every search has to hit every segment, 而如果是term-based segmentation, 明显只需要把这个query仍给负责这个term的Index Searcher, 而省去了整合的步骤, 效率高一些.
当然事物的两面性决定了Document-based segmentation也有他的优点, 就是比较健壮, 当某些服务器crash了, 他还可以返回哪些正常server返回的结果.而term-based segmentation, 如果single term-segment servercrash了, 那么就查询不到任何结果了.
Other Nutch features:
1. Nutch的Query Handler asks each Index Searcher for only a small number of
documents (usually 10).没有必要多, 用户往往只关心first page, top10.
2. 上面说了每个Nutch query会被转化为复杂的lucenne query.
每个index document有3个fields:
the content of the web page itself,
the page’s URL text,
a synthetic document that consists of all the anchor text found in hyperlinks leading to the web page.
Each field has a different weight.
Nutch会生成一个boolean查询去每个field里面搜索.
3.Nutch对于那些在web非常频繁出现的词组(combinations of words)会做特别的index. 因为对于这样的词组, 对每个词单独search然后取交集是低效的.所以Nutch把这样的词组整个当做一个term来处理.这个操作是由Query Handler在预处理时完成的, 在forword给Index Searcher前, 要将这样的词组转化为single special search term.
4. 对于html, Nutch用NekoHTML parser来处理的
5. Nutch 没有用stemming和term alias, 是不是说nutch不处理派生和别名词, 这个问题也在将来也是要解决的
6. Nutch的进程间通信(IPC),在Query Handler和Index Searcher之间维护一个长期的TCP/IP连接.在Query Handler端由许多并发的线程, 任一个线程都能向给定地址的remote server submit a call.
当Server收到一个request时, 会try找到一个注册的service来处理. 而client request 线程会一直block来等通过IPC传来的server的response.如果reponse超时, IPC code会抛异常.
二. Using Lucene at jGuru
jGuru.com is a community-driven site for Java developers.有FAQ, forum等.
首先他要解决的问题就是方便用户得到他所提问题的合适的解答, 这个就是他这个网站的主要目的.
那么他要解决的就是怎么降低论坛posting里面的噪音数据.比如用户提了已经解答过的问题, 或在swing forum里面提database的问题, 或只是在说如''you''re an idiot''之类的废话.怎么办?
1.If there are no Java-related keywords in the post, ask the user to rephrase.
2.If the post uses terminology most likely from a different topic, 建议放到合适的forum
3.Use Lucene to search existing FAQ entries to see if the question has already been answered. If the user does not see the right answer, he or she must manually click Continue to actually submit something to the forum.
这个方法局限性比较大, 不过对于这种内容针对性很强的forum, 倒是一个好方法.
这里用来找Java-related keywords的方法值得借鉴,
New York Times and other web sites, collecting a pool of generic English words.
Then I collected words from our FAQ system, figuring that it was English+Java.
Doing a fuzzy set difference, (Java+English)-English, should result in a set of Java specific words.
这样同样可以对每个子topic去找相关的keywords
jGuru在做index时, 分了4个目录, 这样可以分别search, 然后汇总.
/var/data/search/faq—Content from jGuru FAQs
/var/data/search/forum—Content from jGuru forums
/var/data/search/foreign—Content spidered from non-jGuru sources
/var/data/search/guru—Content related to jGuru users
其他的貌似没有什么特别的地方, 就不具体讲了
作为用lucene实现的开源search engine怎么使用lucene的了.
Nutch用了许多个的lucene indexes放在不同的server上, 因为是面对Web-scale的, document数目在1-10billion量级, 非常的多, 必须用许多机器同时去进行index和search操作. 而且在query的时候需要快速反应, 不能因为某个server crash了而影响正常的query.
Nutch的query architecture是相当简单的, 描述如下:
1. HTTP server接受到用户request.有个叫Query Handler的servlet来处理这个request, 并返回结果页面给用户.
2. Query Handler先对这个request做一些处理(parse request,转化为search terms), 然后forward这个query的search terms给Index Searcher machines的集群.Nutch的查询看起来要比lucene的简单的多, 就是说nutch设计了一套更简单,便于用户使用的query language, 所以这里要将Nutch query转化为具体的Lucene query.这个后面会再讨论. 每个Index Searcher并行工作, 最后返回各自的ranked list(document ids).
3. 最后有许多的search results streams返回给了Query Handler.他收集结果, 并从中找出最好的ranking list.如果有些Index Searcher超时, 没有返回结果, 就ignore他.
深入探讨一下:
前面说了Query Handler会request做些轻量级的预处理, 如去掉stop word. 然后他去并行的同时去contact 许多的Index Searcher, 实际上考虑到系统的robustness, 一个document segment会被copy到多个不同的server上, 对于每个document segment, Query Handler会随机选一个Index Searcher server来做search. 如果某个server没反应, 他会将这个server标记为unavailable, 以后就不选他了.(当然Query Handler会定时轮询各个server, 把恢复的server置成可用).
一直在说Nutch用了很多indexes, 可是Nutch按什么标准把一个huge的indexes文件, 分成很多小index了. 这个问题是在做search engine design时, 必须要回答的基本问题.
一般有两种选择, 按document分和按search term分.
比如可以把所有含有''parrot''的文档都让一个单独的Index Searcher去负责, 或把来自''http://nutch.org''的文档都让一个Index Searcher去负责. 这个只是举个例子, 分的方法有很多, 比如我一下就想到用hash.
Nutch选择了后者即Document-based segmentation, 感觉这个容易实现一点
他明显的缺点是every search has to hit every segment, 而如果是term-based segmentation, 明显只需要把这个query仍给负责这个term的Index Searcher, 而省去了整合的步骤, 效率高一些.
当然事物的两面性决定了Document-based segmentation也有他的优点, 就是比较健壮, 当某些服务器crash了, 他还可以返回哪些正常server返回的结果.而term-based segmentation, 如果single term-segment servercrash了, 那么就查询不到任何结果了.
Other Nutch features:
1. Nutch的Query Handler asks each Index Searcher for only a small number of
documents (usually 10).没有必要多, 用户往往只关心first page, top10.
2. 上面说了每个Nutch query会被转化为复杂的lucenne query.
每个index document有3个fields:
the content of the web page itself,
the page’s URL text,
a synthetic document that consists of all the anchor text found in hyperlinks leading to the web page.
Each field has a different weight.
Nutch会生成一个boolean查询去每个field里面搜索.
3.Nutch对于那些在web非常频繁出现的词组(combinations of words)会做特别的index. 因为对于这样的词组, 对每个词单独search然后取交集是低效的.所以Nutch把这样的词组整个当做一个term来处理.这个操作是由Query Handler在预处理时完成的, 在forword给Index Searcher前, 要将这样的词组转化为single special search term.
4. 对于html, Nutch用NekoHTML parser来处理的
5. Nutch 没有用stemming和term alias, 是不是说nutch不处理派生和别名词, 这个问题也在将来也是要解决的
6. Nutch的进程间通信(IPC),在Query Handler和Index Searcher之间维护一个长期的TCP/IP连接.在Query Handler端由许多并发的线程, 任一个线程都能向给定地址的remote server submit a call.
当Server收到一个request时, 会try找到一个注册的service来处理. 而client request 线程会一直block来等通过IPC传来的server的response.如果reponse超时, IPC code会抛异常.
二. Using Lucene at jGuru
jGuru.com is a community-driven site for Java developers.有FAQ, forum等.
首先他要解决的问题就是方便用户得到他所提问题的合适的解答, 这个就是他这个网站的主要目的.
那么他要解决的就是怎么降低论坛posting里面的噪音数据.比如用户提了已经解答过的问题, 或在swing forum里面提database的问题, 或只是在说如''you''re an idiot''之类的废话.怎么办?
1.If there are no Java-related keywords in the post, ask the user to rephrase.
2.If the post uses terminology most likely from a different topic, 建议放到合适的forum
3.Use Lucene to search existing FAQ entries to see if the question has already been answered. If the user does not see the right answer, he or she must manually click Continue to actually submit something to the forum.
这个方法局限性比较大, 不过对于这种内容针对性很强的forum, 倒是一个好方法.
这里用来找Java-related keywords的方法值得借鉴,
New York Times and other web sites, collecting a pool of generic English words.
Then I collected words from our FAQ system, figuring that it was English+Java.
Doing a fuzzy set difference, (Java+English)-English, should result in a set of Java specific words.
这样同样可以对每个子topic去找相关的keywords
jGuru在做index时, 分了4个目录, 这样可以分别search, 然后汇总.
/var/data/search/faq—Content from jGuru FAQs
/var/data/search/forum—Content from jGuru forums
/var/data/search/foreign—Content spidered from non-jGuru sources
/var/data/search/guru—Content related to jGuru users
其他的貌似没有什么特别的地方, 就不具体讲了
