集中/分布式搜索引擎的4种设计方案

对于搜索引擎, 在索引量和搜索量大到一定程度的时候, 索引更新的效率会逐渐降低, 服务器的压力逐渐升高, 因此基本上整个搜索引擎的利用率可以说是越来越低了, 并且随着海量数据存储带来的困难, 设计一个良好的分布式搜索引擎将是一个搜索引擎能否面相未来发展的关键因素了.
那么分布式搜索引擎的最主要的核心问题是哪些呢?
1. 分布的信息获取和计算以及对此进行的数据统一
这里面包括爬虫/或者相应的数据获取机制的分布, 对信息进行加工的统一管理
2. 数据处理后的分布存储和管理
主要是文件的准确定位和更新,增加,删除,移动的机制
3. 前端搜索服务的分布
主要处理大规模并发请求时的分发机制
基于以上3个基本需求, 基本上可以构造如下4类的分布式搜索引擎:
1. 分布式元搜索引擎
2. 散列分布搜索引擎
3. P2P 分布搜索引擎
4. 局部遍历型搜索引擎
下面逐步介绍以上4类可扩展的搜索引擎:
1. 分布式元搜索:
拥有多个单个的搜索引擎, 中心搜索引擎是利用这些分布的单个的搜索引擎的结果进行撮合得到完整的结果.
这样的设计方案要求各个单元的搜索引擎拥有相同的排序算法和基本相同的数据输出结构,以便由中心搜索进行整理。
对于这类的搜索引擎,关键的设计是要求每一个单元所拥有的索引不构成重复,但是进行数据的采集(爬虫)时可以采取独立的系统获取后再按照规则分布到各个单元上。
优点,设计简单,快速,并且任何一个单元可以随时的摘掉但并不影响太大。
缺点,对于大规模的并发并非好的解决办法
2.散列分布搜索引擎
根据Query对索引服务器和文档服务器进行散列,做到对于任何的索引词能够准确的定位到具体的索引服务器并从而定位到正确的文档服务器。
优点,抗压,设计简单
缺点,对于单个索引服务器或者文档服务器的容量等动态的调整较困难
3.Peer 2 peer 搜索引擎
著名的Napster就是这样的一种设计,利用集中方式的索引,配合分布于世界各地的单个的计算机形成的文件源,构成了世界上最庞大的p2p搜索引擎之一。
这种设计里的中心索引服务器只记录一些相对关键的信息,例如位置(IP,序列号),歌曲的名字,作者等,其它的信息一概可以从任何在线并且拥有本条全面信息的计算机上获取。同时p2p也可以根据搜索建立一些中间路由的缓存,即将一些搜索结果存在单个或者相近的节点上,加快搜索速度。
优点,可以超级大,基本上不需要有维护成本

时间: 2024-10-28 14:51:26

集中/分布式搜索引擎的4种设计方案的相关文章

谈谈分布式事务之四: 两种事务处理协议OleTx与WS-AT

在年前写一个几篇关于分布式事务的文章,实际上这些都是为了系统介绍WCF事务处理体系而提供的相关的背景和基础知识.今天发最后一篇,介绍分布式事务采用的两种协议,即OleTx和WS-AT,内容比较枯燥,但对于后续对WCF事务处理框架进行深入剖析的系列文章来说,确是不可以缺少的.总的来说,基于WCF的分布式事务采用的是两阶段提交(2PC:Two Phase Commit)协议.具体来说,我们可以选择如下两种事务处理协议实现WCF的分布式式事务,它们按照各自的方式提供了对两阶段提交的实现. OleTx:

hash和solr在海量数据分布式搜索引擎中的应用教程

  Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口.用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引. 互联网创业中大部分人都是草根创业,这个时候没有强劲的服务器,也没有钱去买很昂贵的海量数据库.在这样严峻的条件下,一批又一批的创业者从创业中获得成功,这个和当前的开源技术.海量数据架构有着必不可分的关系.比如我们使用mysql.nginx等开源软件,通过架构和低成本服务器也可以搭建千万级用户访问量的系统.新浪微博.淘宝网.

ORM数据层框架的设计热点:更新指定的列的几种设计方案

ORM框架的定义:对象-关系映射(Object/Relation Mapping,简称ORM) 常见的是:数据库结构=>映射Object(实体属性)=>基于实体类的操作. 还有一种:数据库结构=>映射Object(内存表结构)=>基于内存表的操作. 当然,如果你有创意,你还能创造出更多的映射载体来实现ORM. 避免思维定式:  由于思维定式,很多开发者,只有见到基于实体类映射,才会认为是一种ORM框架,于是很少人去思考其它映射载体来实现ORM. 这个思维定式,和早期在ASP.NET

手把手,教你用MaxCompute+OpenSearch搭建分布式搜索引擎

背景 最近,经常有客户咨询如何低成本搭建高性能的海量数据搜索引擎,比如实现公众号检索.影讯检索等等.由于客户的数据在阿里云上,所以希望找到云上解决方案.笔者开始调研一些云上产品,很多人向我推荐了OpenSearch,所以花了点时间好好研究了下,用过之后发现效果不错,自带分词.云数据库同步功能,在研究过程中也发现了一些问题,分享给大家. 接下来,我们开始用阿里云MaxCompute(原名ODPS)和OpenSearch来搭建一个影讯检索的搜索引擎Demo,我有大约10GB数据,服务搭建只用了15分

网站是否被搜索引擎惩罚五种分析方法浅析

每次百度更新的时候,总是几家欢喜几家愁,有的网站排名提升了,有的网站排名下降了,很多站长一旦发现自己网站排名下降了就会非常的担心自己的网站是不是被搜索引擎K站了,或者是被降权了,可是仅仅通过排名下降就确认网站被K或者降权那是非常不科学的,往往会导致自己做大量的无用功甚至做出对网站不利的事情,对此分析网站是否被K或者被降权是非常重要的!其中有五种分析方法笔者认为比较好用,下面就和广大的站长朋友们分享一下! 一:使用百度的site命令分析,具体的操作方法是在搜索引擎的对话框里面输入site:网站域名

waterfall瀑布流网页实现的两种设计方案Masonry与KISSY

waterfall瀑布流网页实现的设计方案一:Masonry waterfall 瀑布流网页实现的设计方案一:Masonry(含loading几次后出现分页) 瀑布流设计早就不是什么新鲜的东西了,现在网上基于瀑布流的网页非常常见,这种设计能给浏览器者更直接更有效率的浏览体验. 那么我们可以如何从前端.后端配合去实现这种效果呢? 其实目前已有很多基于jquery或原生态javascript的waterfall插件,我们只需要根据api进行运用,既可做到不错的瀑布流网页. 但是在这些插件中,做得兼容

分布式锁的三种实现方式

分布式锁大有用途,比如用在减库存操作.流水号生成,分布式计数器等.分布式锁服务在大家的项目中或许用的不多,因为大家都把排他放在数据库那一层来挡.当大量的行锁.表锁.事务充斥着数据库的时候.一般web应用很多的瓶颈都在数据库上,这里给大家介绍的是减轻数据库锁负担的方案--分布式锁服务.本文介绍分布式锁常用的三种实现方式.   一.zookeeper 1.实现原理: 基于zookeeper瞬时有序节点实现的分布式锁,其主要逻辑如下(该图来自于IBM网站).大致思想即为:每个客户端对某个功能加锁时,在

许金:总结会被搜索引擎惩罚的几种情况

很多朋友在进行SEO时过于操之过急,难免会发生些意外.做SEO大部分都是靠搜索引擎来获取流量,而在中国更多依靠的是百度.经常会有被搜索引擎惩罚的情况出现,为了使更多的人少走弯路,这里罗列几点避免被搜索引擎惩罚的情况. 一.标题 很多时候SEOer为了优化大量的关键词将其堆积在标题里,大大地超过了标题所允许的字数.建议3-4个关键词即可,当然可以利用分词的原则来做标题,例如"安徽合肥SEO_电子商务_网络营销" 这个标题利用分词原理,就可以出现很多关键词.另外权重不高的情况下切勿经常修改

浅析容易惹毛搜索引擎的几种优化策略

作为我们SEOer说难听点就是靠搜索引擎吃饭的.在我们这个网络的"社会"中,搜索结果不是访客说的算,更不是网站说的算,而是要由搜索引擎来决定.做内的网名戏称百度为度娘,而作为我们SEOer就是生活在度娘的淫威下.那么如何在日常的优化中既达到优化的效果又不惹毛搜索引擎就显得直观重要了.那么笔者今天就分享几个我们在日常优化中容易惹毛搜索引擎的策略,希望对大家有所帮助. 一:优化绝对不能太心急 这是最重要的一点,优化的过程是一个缓慢的过程.有可能你的优化一两个月都看不出有什么大的效果.此时你