以下为个人整理,当然并没有把所有的都研究完。有些仅仅是兴趣而已。
elasticsearch:是一个分布式基于云计算的搜索引擎。主要包括以下特性:
1.分布式、高可用的搜索引擎
2.支持索引分区,并可以灵活配置
3.每个节点可以有多个备份,这样容错性好
4.多类型,每个类型可以多索引
5.丰富的api,支持RESTful方式的api
6.不需要对模型进行预定义,模型可以根据类型来定制
7.接近于实时搜索(个人觉得这点应该是个看点,实时搜索越来越重要,如Facebook,twitter等这类网站)
8.构建于Lucene之上
katta:是可扩展性、容错机制、分布式的、并且是准实时的。
1.可以轻松构建超大服务集群,拥有自我复制功能、索引碎片机制,承载高访问量和存储大数据量。
2.索引碎片可以 有 不同的格式, 当前只支持lucene索引文件和hadoop mapfiles.
3.可以轻松构建大数据量和高负载的环境
4.拆分lucene索引或者hadoop map files成文件碎片存放到多台服务器上
5.自动复制碎片功能,从而达到高性能和容错功能
6.很容易扩展集群 Master故障切换
7.快速的、轻量级的、非常容易整合
8.在hadoop分布式集群上运行的很好
Lucene作为一个全文检索引擎,其具有如下突出的优点:
(1)索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式,使得兼容
系统或者不同平台的应用能够共享建立的索引文件。
(2)在传统全文检索引擎的倒排索引的基础上,实现了分块索引,能够针对新的文件建立小文件索
引,提升索引速度。然后通过与原有索引的合并,达到优化的目的。
(3)优秀的面向对象的系统架构,使得对于Lucene扩展的学习难度降低,方便扩充新功能。
(4)设计了独立于语言和文件格式的文本分析接口,索引器通过接受Token流完成索引文件的创立,
用户扩展新的语言和文件格式,只需要实现文本分析的接口。
(5)已经默认实现了一套强大的查询引擎,用户无需自己编写代码即使系统可获得强大的查询能力,
Lucene的查询 实现中默认实现了布尔操作、模糊查询、分组查询等等。
Sphinx:支持高速建立索引(可达10MB/秒,而Lucene建立索引的速度是1.8MB/秒)
高性能搜索(在2-4 GB的文本上搜索,平均0.1秒内获得结果)
高扩展性(实测最高可对100GB的文本建立索引,单一索引可包含1亿条记录)
支持分布式检索
支持基于短语和基于统计的复合结果排序机制
支持任意数量的文件字段(数值属性或全文检索属性)
支持不同的搜索模式(“完全匹配”,“短语匹配”和“任一匹配”)
支持作为Mysql的存储引擎
Heritrix: 是个归档爬虫 -- 用来获取完整的、精确的、站点内容的深度复制。
1.获取图像以及其他非文本内容。抓取并存储相关的内容。
2.对内容来者不拒,不对页面进行内容上的修改。重新爬行对相同的URL不针对先前的进行替换。
3.爬虫通过Web用 户界面启动、监控、调整,允许弹性的定义要获取的URL。
Nutch :是一个开源的、Java 实现的搜索引擎。它提供了搜索引擎所需的全部工具。包括全文搜索和Web爬
虫。
爬取部分:
1 . 创建一个新的WebDb (admin db -create).
2. 将抓取起始URLs写入WebDB中 (inject).
3. 根据WebDB生成fetchlist并写入相应的segment(generate).
4. 根据fetchlist中的URL抓取网页 (fetch).
5. 根据抓取网页更新WebDb (updatedb).
6. 循环进行3-5步直至预先设定的抓取深度。
7. 根据WebDB得到的网页评分和links更新segments (updatesegs).
8. 对所抓取的网页进行索引(index).
9. 在索引中丢弃有重复内容的网页和重复的URLs (dedup).
10. 将segments中的索引进行合并生成用于检索的最终index(merge).
搜索部分:
1. WebDB:包含pages和links的网络图。
2. segments集:包含了fetcher从web中获取的原始数据。
3. 合成的index:对segments进行索引和消重分析得到。
备注:个人感觉一次爬完才能生产索引,特别郁闷(也许可以还有其他的方式?)。现在nutch2.0的蓝
图也出来了,有比较大的手术。nutch的存储系统Hadoop已经远远超过nutch本身了。分布式,并行计算,
海里数据排序,统计处理Hadoop很适合。
solr:solr虽然做个项目,可是因为不是自己负责,竟然没看过多少。
Zoie:(引用)通常的检索系统 中,建索引和查询是分开的,即建索引是离线的,新的 索引会以一定频率(比如每隔5分钟)供查询端使用。对于一些站内检索来说,这种延迟性使得:不需要建索引的速度足够快(只要能跟的上提交频率就行),查询 的效果不必完全精确。而要取得实时检索效果,典型的思路是:建索引和查询是在一个进程内,这样每一次的添加索引都会被下一次的查询用到,但这里面的细节还 是需要好好琢磨解决 的,下面就给出Zoie的基于Lucene的解决方案 :索引分两种,ram index和disk index。建索引的过程是:首先建立ram index,因为是内存操作,这个过程通常较快,建完后会重新打开IndexReader,使查询端能看到最新的索引;当内存中的索引文档 数达到阈值(10000)或者间隔时间达到阈值(自 定义),一个后台线程就将ram index合并到disk index里去,完成后清空已经无用的ram index,并重新打开disk index的IndexReader供查询使用(这里面有个autowarm IndexReader的过程)。特别指出的是,Zoie的ram index有两个,这使得当一个ram index在和disk index做合并操作时(这个过程可能会很耗时),另一个ram index仍能提供建索引的操作。对于查询,使用的索引就包括两个ram index和一个disk index,所以只要索引在内存里建好,就能查询到最新的数据
Lily:
Lily以NoSQL技术为主题,是建立在云计算上的内容仓库(content repository)。它是基于Apache的 HBase(存储)和Solr(索引/搜索),并提供了大型内容集合存储与检索的解决方案。可运用在 门户网站,内容管理系统,及时搜索,档案应用,文案管理,等等。