主流全文索引工具的比较( Lucene, Sphinx, solr, elastic search)

发布时间: 2012-06-15 12:56:00

前几天的调研( Rails3下的 full text search (全文本搜索, 全文匹配?) ), 我发现了两个不错的候选:

1. lucene  (solr, elasticsearch 都是基于它)

2. sphinx



回答1.  Result relevance ranking is the default. You can set up your own sorting should you wish, and give specific fields higher weightings.
结果相关度 是排序的默认条件。你也可以自行指定,也可以配置不同列的权重。

Indexing speed is super-fast, because it talks directly to the database. Any slowness will come from complex SQL queries and un-indexed foreign keys and other such problems. I've never noticed any slowness in searching either.

The search service daemon (searchd) is pretty low on memory usage - and you can set limits on how much memory the indexer process uses too.

Scalability is where my knowledge is more sketchy - but it's easy enough to copy index files to multiple machines and run several searchd daemons. The general impression I get from others though is that it's pretty damn good under high load, so scaling it out across multiple machines isn't something that needs to be dealt with.
扩展性: 我对它了解的不多。但是很容易把一份索引COPY到多个服务器上,然后再跑多个搜索进程。  从其他人那里了解的情况是:在高压高并发下,单极表现就足够好了!所以没必要考虑把它做成分布式。。。

There's no support for 'did-you-mean', etc - although these can be done with other tools easily enough. Sphinx does stem words though using dictionaries, so 'driving' and 'drive' (for example) would be considered the same in searches.
它不支持查询纠正(“你是不是想搜索OOXX”? )  Sphinx 使用字典进行分词,所以driving 和 drive 返回的搜索结果是一样的。

I don't know Sphinx, but as for Lucene vs a database full-text search, I think that Lucene performance is unmatched. You should be able to do almost any search in less than 10 ms, no matter how many records you have to search, provided that you have set up your Lucene index correctly.

Here comes the biggest hurdle though: personally, I think integrating Lucene in your project is not easy. Sure, it is not too hard to set it up so you can do some basic search, but if you want to get the most out of it, with optimal performance, then you definitely need a good book about Lucene.

As for CPU & RAM requirements, performing a search in Lucene doesn't task your CPU too much, though indexing your data is, although you don't do that too often (maybe once or twice a day), so that isn't much of a hurdle.
检索时它对CPU和内存的需求很小, 建立索引时却不小,不过估计你每天重建索引的次数也不多,所以估计问题不大。
elasticsearch 的作者的回答:

As the creator of ElasticSearch, maybe I can give you some reasoning on why I went ahead and created it in the first place.

Using pure Lucene is challenging. There are many things that you need to take care for if you want it to really perform well, and also, its a library, so no distributed support, its just an embedded Java library that you need to maintain.

In terms of Lucene usability, way back when (almost 6 years now), I created Compass. Its aim was to simplify using Lucene and make everyday Lucene simpler. What I came across time and time again is the requirement to be able to have Compass distributed. I started to work on it from within Compass, by integrating with data grid solutions like GigaSpaces, Coherence and Terracotta, but its not enough.
在使用性方面。。。还得谈及6年前我建立 Compass 这个项目。它的目的是把使用和维护Lucene 变得简单些。而我当时屡次遇到这样的需求:让Compass支持分布式。 于是我以此为起点开始工作, 集成了 data grid 解决方案(例如Gigaspaces .... )但是这些努力还不够。

At its core, a distributed Lucene solution needs to be sharded. Also, with the advancement of HTTP and JSON as ubiquitous APIs, it means that a solution that many different systems with different languages can easily be used.
分布式Lucene解决方案的核心是:  数据库需要水平分区的。(sharded, 词条见:shard  )  同时,还要使用 HTTP 和JSON 的形式来做为API。这样的优势是:不论什么语言,都可以轻易的调用它。

This is why I went ahead and created ElasticSearch. It has a very advance distributed model, speaks natively JSON, and exposes many advance search features, all seamlessly expressed through JSON DSL.
这就是我建立ElasticSearch的原因。  它用有先进的分布式模型, 本地语言是JSON, 还提供了很多查询特性。 这些都使用JSON形式的DSL来访问。

Solr is also a solution for exposing an indexing/search server over HTTP, but I would argue that ElasticSearch provides a much superior distributed model and ease of use (though currently lacking on some of the search features, but not for long, and in any case, the plan is to get all Compass features into ElasticSearch). Of course, I am biased, since I created ElasticSearch, so you might need to check for yourself.
Solr 也是一个通过HTTP 访问的检索/查询解决方案,但是我觉得 ElasticSearch 提供了更好的分布式模型,也更容易使用(尽管目前看来, ElasticSearch还缺少某些检索特性,但是在不远的将来,我保证,会把Compass所有的特性都移植到ElasticSearch中去) 当然了,做为作者,我的话肯定会偏向于ElasticSearch,所以你最好亲自试一下。

As for Sphinx, I have not used it, so I can't comment. What I can refer you is to this thread at Sphinx forum which I think proves the superior distributed model of ElasticSearch.
对于 Sphinx,我没用过。所以也就不评价它了。不过从 Sphinx 论坛的这篇文章看来,ElasticSearch 提供了更好的 分布式模型。

Of course, ElasticSearch has many more features then just being distributed. It is actually built with cloud in mind. You can check the feature list on the site.
当然了,除了更好的分布式模型,ElasticSearch 还提供了很多其他的特性。 因为它的诞生就是基于 分布式的理念(built with cloud in mind),你可以试一下 站点中的特性里面所列举的特性。
I've been using Solr successfully for almost 2 years now, and have never used Sphinx, so I'm obviously biased. However, I'll try to keep it objective by quoting the docs or other people. I'll also take patches to my answer :-)
过去两年我一直在用 Solr,用的很好。从没用过Sphinx. 所以我个人观点肯定不太客观。不过,我引用一下其他人的看法

Similarities: 相同点:

Both Solr and Sphinx satisfy all of your requirements. They're fast and designed to index and search large bodies of data efficiently.
Both have a long list of high-traffic sites using them (Solr, Sphinx)
Both offer commercial support. (Solr, Sphinx)
Both offer client API bindings for several platforms/languages (Sphinx, Solr)
都支持 对不同语言的 CLIENT API。
Both can be distributed to increase speed and capacity (Sphinx, Solr)

Here are some differences: 几点不同:

Solr, being an Apache project, is obviously Apache2-licensed. Sphinx is GPLv2. This means that if you ever need to embed or extend (not just "use") Sphinx in a commercial application, you'll have to buy a commercial license (rationale)
Solr 是 apache的项目,是apache2的license. Sphinx是 GPL,也就是说,如果你想把Sphinx放到某个商业性的项目中,你就得买个商业许可证。

Solr is easily embeddable in Java applications.

Solr is built on top of Lucene, which is a proven technology over 8 years old with a huge user base (this is only a small part). Whenever Lucene gets a new feature or speedup, Solr gets it too. Many of the devs committing to Solr are also Lucene committers.
Solr 是基于Lucene 的,后者已经8岁了,有着庞大的用户群体。Lucene 有啥功能,Solr就能享受到啥功能。而且Solr的 开发人员很多也参与了Lucene的开发。

Sphinx integrates more tightly with RDBMSs, especially MySQL.
Solr can be integrated with Hadoop to build distributed applications
Solr can be integrated with Nutch to quickly build a fully-fledged web search engine with crawler.
Sphinx 跟 RDBMS (特别是MYSQL) 绑定的特别紧密。 而且Solr 可以和 Hadoop 集成,成为分布式系统。 也可以 和 Nutch集成,成为一个功能完备的搜索引擎,以及网络爬虫(crawler)

Solr can index proprietary formats like Microsoft Word, PDF, etc. Sphinx can't.
Solr 可以检索 WORD, PDF。 Sphinx不行

Solr comes with a spell-checker out of the box.
Solr 还带有拼写检查器。

Solr comes with facet support out of the box. Faceting in Sphinx takes more work.
Solr 默认有facet支持。 而Shphinx中就得做一些额外的工作才行

Sphinx doesn't allow partial index updates for field data.
Sphinx 不支持针对field data 的partial index的更新

In Sphinx, all document ids must be unique unsigned non-zero integer numbers. Solr doesn't even require an unique key for many operations, and unique keys can be either integers or strings.
Sphinx中,所有的 document id 必须是 unique , unsigned, non-zero 整数(估计是用C语言的名词来解释)。 Solr的很多操作,甚至不需要unique key。 而且unique key 可以是整数,也可以是字符串。

Solr supports field collapsing (currently as an additional patch only) to avoid duplicating similar results. Sphinx doesn't seem to provide any feature like this.
Solr 支持field collapsing 来避免相似搜索结果的重复性。 Sphinx没这个功能。

While Sphinx is designed to only retrieve document ids, in Solr you can directly get whole documents with pretty much any kind of data, making it more independent of any external data store and it saves the extra roundtrip.
Sphinx只是查询document id, 而solr 则可以查询出整个的document.

Solr, except when used embedded, runs in a Java web container such as Tomcat or Jetty, which require additional specific configuration and tuning (or you can use the included Jetty and just launch it with java -jar start.jar). Sphinx has no additional configuration.
Solr 跑在 java web 容器中,例如Tomcat 或 Jetty. 所以我们就可以进行配置和调试,优化。  Sphinx 则没有额外的配置选项。
有一点比较重要: sphinx不支持 live index update. 支持的话也非常有限。