研讨如何进行Lucene的分布式应用【转】

提问：

　　现在有个项目，有10台服务器，每台服务器负责某一部分的index。另外有一台web服务器，它可以根据用户提交的查询请求到特定的服务器上进行查找。比如用户提交查询A，根据index的分配情况，可以将查询请求分发给服务器a来负责，而用户提交查询请求 B，则将它提交给服务器b来负责。不知lucene目前的index机制和search机制是否能够支持这种需求？

　　

　　回答：

　　1. 目前lucene的机制不支持这种需求

　　2. 你可以很容易的扩展lucene,从而满足你的需求.

　　实际上,你这是涉及到 indexing的分布式存储的问题, 涉及到结构, 传输,等等.

　　所以,你必须要设计一个robust的分布式index结构,然后再考虑如何实现.不要一开始就拿一个开源的lucene就上.

　　google当然是分布式的索引. 只不过这个分布式可能不是你想象中的那么神秘.

　　
　　提问：

　　刚才看了一下lucene的index结构，感觉不需要对index进行修改，比如 10台检索服务器，每个服务器负责一个网站的crawl以及index。然后我的web服务器将用户的query广播到10台检索服务器去，10台服务器同时进行搜索（用lucene的api），然后每台服务器将最符合的topN条记录发送回web服务器，web服务器再对这topN×10条记录进行重新排序，取最前面的topN条记录就行了。

　　你觉得我这种方法可行吗？

　　我觉得这种方法的缺点在于web服务器和检索服务器之间的通讯量问题：

　　1、首先要对10个服务器进行广播查询，有没有方法可以根据query的情况，能够确定对某台服务器查询？感觉这确实要对index进行分布式的存储，但是如何进行分布式存储呢？按照term进行分布式存储肯定不行，因为对单一的term进行查询，返回的文档肯定很多（按照lucene里面的算法），难道按照term vector来分布式存储？好像lucene不太支持这个吧。

　　2、其次，每台检索服务器都返回了topN条结果，这好像比较浪费，有没有什么办法让它返回少点，同时又不影响结果？

　　回答：

　　你的这个结构理论上是可以的，不过有一点：

　　按照你目前的应用规模，你的索引完全可以放在一台机器上。

　　为什么要分开10台机器存储？

　　集中在一台机器上，就没有检索的时候，通讯量的这个问题了。

　　如果你真的是想要分开，就要涉及到分布式索引，和索引之间的通讯压缩的问题，这个也是你提到的困惑，我觉得如果你不是专业SE，你最好绕过这个技术难点。

　　现在的版本已经有进度显示，以及支持索引更新。至于与Jxta有一个based On grid的distributed fulltext search项目的区别，我们目前还没有做过比较，呵呵。distributed search项目意在于提供多个节点之间架构一个平台提供有效的资源查找与资源共享方式。该项目采用lucene(http://lucene.apache.org)开放源项目作为底层的搜索引擎，采用网格技术实现分布式机制。

　　为什么非要扯上“分布”去？

　　我看了半天，还不是太理解你的问题，就我目前的了解，似乎是两种情况。

　　1、检索的负载大，想用多台服务器分散检索的压力。（相对的，全文内容的更新相对压力较小，可以集中用一台高性能服务器来处理全文内容的更新）

　　由于lucene是基于文件的，实现起来比较方便一些。你可以使用NAS做为你的存储，或者是直接采用廉价的同步复制方案（比如rsyncd）。

　　比如10台服务器，用一台处理全文内容更新，另外9台对外提供检索。当全文内容更新后，通过rsyncd这样的同步复制，把更新后的内容同步到9台检索服务器去，供用户检索。

　　至于负载，10台服务器都有了，再花几万块钱买台均衡交换机（比如aleton）也没有太大难处吧？

　　2、检索压力小，全文内容的更新量大。

　　在单台服务器下面，可能就是表现在你的全文库分散在不同的目录下面（比如/full/app1、/full/app2.。），想检索的时候能检索所有的全文记录，而不是某一目录（比如/full/app1），是否？

　　也就是说，你希望用9台服务器来处理全文的增加，比如一台服务器对应一个应用。如果采用NAS（或是其它高速的存储解决方案），或是rsyncd这类同步复制，在任何一个全文服务器有更新后，及时的把这台的更新内容同步到用于检索的10服务器上。

　　在检索的这台服务器上，如同单一服务器一样，同步后的数据按服务器存储在不同目录下，而lucene检索时，好象它的api是支持多目录检索的。

　　另：

　　我觉得你的需求，实际上没有必要扯到“分布”上面去，如果能在存储上花点功夫，比如选择一个比较好的统一存储方案，或是实现存储的“主--镜像”同步复制，也许就不是问题了。

　　对于存储引出来的传输性能问题，你可以在构建网络的时候考虑一下，比如在每个服务器上多加网卡，用光口或是GE口构建一个专门的“传输网络”，避免与“业务网络”、“管理网络”这类塞车，在传输上的问题应该影响不大。

　　我做的分布式lucene搜索,可以把数据源分时间建到不同机器上,每台机器做个seachserver,web服务器同时向各个 seachserver发送请求,10台seachserver同时查询,返回查询条数再从最近的索引库返回结果,翻页的话判断每个每台 seacherserver的条数,以时间最近的机器返回结果!