公司以前有个用Lucene实现的伪分布式项目,实时性不好,后期数据量逐渐增大的时候,数据同步一次须要十几小时。当时项目重构考虑到的是Solr和ES,我参与的是Solr技术的预研。由于项目实时性要求很高,最终选择的是ES。算法
Elasticsearch是一个实时的分布式搜索和分析引擎。它能够帮助你用史无前例的速度去处理大规模数据。它能够用于全文搜索,结构化搜索以及分析,固然你也能够将这三者进行组合。数据库
Elasticsearch是一个创建在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎,能够说Lucene是当今最早进,最高效的全功能开源搜索引擎框架。可是Lucene只是一个框架,要充分利用它的功能,须要使用JAVA,而且在程序中集成Lucene。须要不少的学习了解,才能明白它是如何运行的,Lucene确实很是复杂。apache
Elasticsearch使用Lucene做为内部引擎,可是在使用它作全文搜索时,只须要使用统一开发好的API便可,而不须要了解其背后复杂的Lucene的运行原理。json
固然Elasticsearch并不只仅是Lucene这么简单,它不但包括了全文搜索功能,还能够进行如下工做:
一、分布式实时文件存储,并将每个字段都编入索引,使其能够被搜索。
二、实时分析的分布式搜索引擎。
三、能够扩展到上百台服务器,处理PB级别的结构化或非结构化数据。服务器
这么多的功能被集成到一台服务器上,你能够轻松地经过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流。Elasticsearch的上手是很是简单的。它附带了不少很是合理的默认值,这让初学者很好地避免一上手就要面对复杂的理论,它安装好了就可使用了,用很小的学习成本就能够变得颇有生产力。网络
随着越学越深刻,还能够利用Elasticsearch更多高级的功能,整个引擎能够很灵活地进行配置。能够根据自身需求来定制属于本身的Elasticsearch。架构
使用案例:
一、维基百科使用Elasticsearch来进行全文搜作并高亮显示关键词,以及提供search-as-you-type、did-you-mean等搜索建议功能。
二、英国卫报使用Elasticsearch来处理访客日志,以便能将公众对不一样文章的反应实时地反馈给各位编辑。
三、StackOverflow将全文搜索与地理位置和相关信息进行结合,以提供more-like-this相关问题的展示。
四、GitHub使用Elasticsearch来检索超过1300亿行代码。
五、天天,Goldman Sachs使用它来处理5TB数据的索引,还有不少投行使用它来分析股票市场的变更。
可是Elasticsearch并不仅是面向大型企业的,它还帮助了不少相似DataDog以及Klout的创业公司进行了功能的扩展。composer
Solr(读做“solar”)是Apache Lucene项目的开源企业搜索平台。
其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成,以及富文本(如Word、PDF)的处理。
Solr是高度可扩展的,并提供了分布式搜索和索引复制。
Solr是最流行的企业级搜索引擎,Solr4 还增长了NoSQL支持。
Solr是用Java编写、运行在Servlet容器(如 Apache Tomcat 或Jetty)的一个独立的全文搜索服务器。
Solr采用了 Lucene Java搜索库为核心的全文索引和搜索,并具备相似REST的HTTP/XML和JSON的API。
Solr强大的外部配置功能使得无需进行Java编码,即可对其进行调整以适应多种类型的应用程序。Solr有一个插件架构,以支持更多的高级定制。框架
由于2010年 Apache Lucene 和 Apache Solr 项目合并,两个项目是由同一个Apache软件基金会开发团队制做实现的。提到技术或产品时,Lucene/Solr或Solr/Lucene是同样的。机器学习
创建索引时,搜索效率降低,实时索引搜索效率不高。
当单纯的对已有数据进行搜索时,Solr更快。
当实时创建索引时, Solr会产生io阻塞,查询性能较差, Elasticsearch具备明显的优点。
随着数据量的增长,Solr的搜索效率会变得更低,而Elasticsearch却没有明显的变化。
综上所述,Solr的架构不适合实时搜索的应用。
下图为将搜索引擎从Solr转到Elasticsearch之后的平均查询速度有了50倍的提高。
说明:Lucene 是一个 JAVA 搜索类库,它自己并非一个完整的解决方案,须要额外的开发工做。
优势:成熟的解决方案,有不少的成功案例。apache 顶级项目,正在持续快速的进步。庞大而活跃的开发社区,大量的开发人员。它只是一个类库,有足够的定制和优化空间:通过简单定制,就能够知足绝大部分常见的需求;通过优化,能够支持 10亿+ 量级的搜索。
缺点:须要额外的开发工做。全部的扩展,分布式,可靠性等都须要本身实现;非实时,从建索引到能够搜索中间有一个时间延迟,而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善
说明:基于 Lucene 的,支持分布式,可扩展,具备容错功能,准实时的搜索方案。
优势:开箱即用,能够与 Hadoop 配合实现分布式。具有扩展和容错机制。
缺点:只是搜索方案,建索引部分仍是须要本身实现。在搜索功能上,只实现了最基本的需求。成功案例较少,项目的成熟度稍微差一些。由于须要支持分布式,对于一些复杂的查询需求,定制的难度会比较大。
说明:Map/Reduce 模式的,分布式建索引方案,能够跟 Katta 配合使用。
优势:分布式建索引,具有可扩展性。
缺点:只是建索引方案,不包括搜索实现。工做在批处理模式,对实时搜索的支持不佳。
说明:基于 Lucene 的一系列解决方案,包括 准实时搜索 zoie ,facet 搜索实现 bobo ,机器学习算法 decomposer ,摘要存储库 krati ,数据库模式包装 sensei 等等
优势:通过验证的解决方案,支持分布式,可扩展,丰富的功能实现
缺点:与 linkedin 公司的联系太紧密,可定制性比较差
说明:基于 Lucene,索引存在 cassandra 数据库中
优势:参考 cassandra 的优势
缺点:参考 cassandra 的缺点。另外,这只是一个 demo,没有通过大量验证
说明:基于 Lucene,索引存在 HBase 数据库中 优势:参考 HBase 的优势 缺点:参考 HBase 的缺点。另外,在实现中,lucene terms 是存成行,但每一个 term 对应的 posting lists 是以列的方式存储的。随着单个 term 的 posting lists 的增大,查询时的速度受到的影响会很是大