开发垂直门户的分布式搜索引擎系统

最近遇到了头疼的事情，就是开发垂直门户的分布式搜索引擎系统时，发现有四种不同应用的分布式搜索引擎： 1.分布式元搜索: 拥有多个单个的搜索引擎, 中心搜索引擎是利用这些分布的单个的搜索引擎的结果进行撮合得到完整的结果. 这样的设计方案要求各个单元的搜索引擎拥有相同的排序算法和基本相同的数据输出结构，以便由中心搜索进行整理。 ２．散列分布搜索引擎 根据Query对索引服务器和文档服务器进行散列，做到对于任何的索引词能够准确的定位到具体的索引服务器并从而定位到正确的文档服务器。 ３．Peer 2 peer 搜索引擎 利用集中方式的索引，配合分布于世界各地的单个的计算机形成的文件源，构成了世界上最庞大的p2p搜索引擎之一。 这种设计里的中心索引服务器只记录一些相对关键的信息，例如位置（IP，序列号），歌曲的名字，作者等，其它的信息一概可以从任何在线并且拥有本条全面信息的计算机上获取。同时p2p也可以根据搜索建立一些中间路由的缓存，即将一些搜索结果存在单个或者相近的节点上，加快搜索速度。 4.局部遍历型搜索引擎 这类的搜索引擎又可以采用多种设计方案，其中比较可行的是对信息进行聚类后建立信息树，搜索时只需要从树的一个分支下去遍历便可以了。局部遍历应当有一定的规则，并且在设计初期就需要对每一个加入的索引进行相对准确的位置安排，使得放置在合适的节点上，以保证搜索的效率。 根据我们的应用需求，觉得第三种显然不适合我们。第二种可能后台的处理工作量巨大。现在的问题是： 在第一种分布式元搜索和局部遍历型搜索引擎之间的应如何取舍？ 两种引擎在应用中的优缺点是什么？ 有没有可能将两种引擎结合起来开发？ 对于资源及设备需求来说，哪种的资源要求比较高？ 看看是否有前辈高人帮助指点一下？或者进行一些探讨？

	回复人：yy8354(平静等待) ( ) 信誉：100	2006-12-30 17:30:54	得分:0
?	我觉得第一种比较合适垂直搜索引擎并非通用抓的那么广泛 所以建立索引的时候以数据源的节点来考虑建立索引 每个节点对应一个搜索 最后合并索引结果就比较方便而且相对不需要考虑分布式索引检索的问题 同时由于索引相对独立 因此单个索引的数据也小 搜索速度上也要提高同时最后的合并结果的服务器那边加个cache服务器 提高速度和结构设计上都比较简单 甚至为了再进一步提高效率 在结果上进行聚类 而非索引上聚类也是种办法
Top

	回复人：yy8354(平静等待) ( ) 信誉：100	2006-12-31 9:15:24	得分:0
?	昨天赶着下班回家 忘记重要的几点没说 第一种的设计上 一个节点挂掉 不影响整体的 最多就是少一些搜索结果 合并结果服务器可多可少 而且通过网关服务器来分流到不同的合并结果服务器上 可以很简单的实现负载平衡 第四种的设计上考虑的信息树的数据量问题 这个树必须有多个copy 才能保证分流 否则信息树服务器挂了 那你系统就over了 除非你的信息树相对较小 否则内存上的消耗量 那是非一般的
Top

	回复人：lixiaobai() ( ) 信誉：100	2006-12-31 10:01:57	得分:0
?	我觉得应该用 局部遍历型搜索引擎 + 分布式元搜索 就是说先使用 局部遍历型搜索 建立起搜索引擎 然后再 部署多个这个的搜索系统 为其建立一个统一界面 形成 分布式元搜索 因为首先 不可能直接有 分布式元搜索 因为无法估计你的每一个垂直搜索类别的数据量 当然 如果人为限制 那么也行 不过 适用范围将大大缩小 也无法保证你的每一个元 有足够的性能 局部遍历型搜索 是一个可以大容量 高负荷运行的结构 散列分布搜索引擎 和 Peer 2 peer 搜索引擎 我觉得对于大型系统 是有缺陷的
Top

	回复人：xxlcg(☆突突☆) ( ) 信誉：100	2007-1-10 10:56:18	得分:0
?	我觉得（散列分布搜索引擎/局部遍历型搜索引擎）+分布式元搜索 散列分布或者局部遍历的下一层再使用元搜索 其实使用散列还是局部遍历要看你垂直领域的业务特点，能容易抽成散列就散列，否则就局部
Top

	回复人：lshuy2001(洋洋) ( ) 信誉：100	2007-1-12 17:37:09	得分:0
?	有个问题想问问 就是信息的排序，一般搜索引擎都是按照相关度来排序，如果多个服务器搜索的时候，搜索到的结果的排序肯定不同吧！这个时候 中心 是否还要排序，如果排序的话，做一个循环，是不是很费时间。