ElasticSearch、Sphinx、Lucene、Solr、Xapian。哪个适合哪个用途?[关闭]
-
20-09-2019 - |
解决方案
由于ElasticSearch的创造者,也许我可以给你我为什么说干就干,首先创建它的一些推理。)
使用纯Lucene是具有挑战性的。还有,你需要照顾的,如果你希望它真的表现好很多事情,而且,它的图书馆,所以没有分布的支撑,它只是你需要保持一个嵌入式Java库。
在Lucene的可用性方面,归途时(几乎6年了),我创建罗盘。其目的是使用Lucene简化和使日常Lucene的简单。我跨越时间和时间来又是要能够有指南针分布的要求。我开始从内部罗盘,通过与像GigaSpaces的,连贯性,和Terracotta数据网格解决方案集成在它的工作,但还不够。
在其核心,一个分布式Lucene的解决方案需要分片。此外,利用HTTP和JSON作为普遍存在的API的进步,这意味着可以很容易地使用的溶液与不同的语言的许多不同的系统。
这就是为什么我说干就干,创建ElasticSearch。它有一个非常先进的分布式模型,讲本地JSON,并公开了许多先进的搜索功能,都通过JSON DSL无缝地表示。
Solr的是也用于暴露通过HTTP索引/搜索服务器的溶液中,但我认为 ElasticSearch 提供了更卓越的分布式模型和易用性(虽然目前尚缺乏对一些搜索功能,但时间不长,在任何情况下,该计划是让所有的指南针的特征分成ElasticSearch)。当然,我有偏见,因为我创建ElasticSearch,所以你可能需要检查自己。
至于斯芬克斯,我还没有使用过,所以我不能评论。我可以把你就是这个线程在狮身人面像论坛我认为这证明了ElasticSearch的优越分布式模型。
当然,ElasticSearch有许多不仅仅是被分发更多的功能。它实际上是用一记云建。您可以查看网站上的功能列表。
其他提示
我使用过 Sphinx、Solr 和 Elasticsearch。Solr/Elasticsearch 构建在 Lucene 之上。它添加了许多常用功能:Web 服务器 api、faceting、缓存等。
如果您只想进行简单的全文搜索设置,Sphinx 是更好的选择。
如果您想自定义搜索,Elasticsearch 和 Solr 是更好的选择。它们具有很强的可扩展性:您可以编写自己的插件来调整结果评分。
一些用法示例:
- 狮身人面像:craigslist.org
- 索尔:Cnet、Netflix、digg.com
- 弹性搜索:四方,Github
我们定期使用Lucene来索引和搜索数千万个文档。搜索足够快,我们使用不需要很长时间的增量更新。我们确实花了一些时间到达这里。Lucene的强调是其可扩展性,众多功能和活跃的开发人员社区。使用Bare Lucene需要在Java中进行编程。
如果您要重新开始,Lucene 系列中适合您的工具是 索尔, ,它比裸露的 Lucene 更容易设置,并且几乎拥有 Lucene 的所有功能。它可以轻松导入数据库文档。Solr 是用 Java 编写的,因此对 Solr 的任何修改都需要 Java 知识,但只需调整配置文件就可以做很多事情。
我还听说过有关 Sphinx 的好消息,尤其是与 MySQL 数据库结合使用时。不过还没用过。
IMO,您应该根据以下条件进行选择:
- 所需的功能 - 例如您需要法语词干提取器吗?Lucene和Solr都有一个,其他的我不知道。
- 熟练掌握实现语言 - 如果您不懂 Java,请不要接触 Java Lucene。您可能需要 C++ 才能使用 Sphinx 进行操作。Lucene也被移植到 其他 语言. 。如果您想扩展搜索引擎,这一点非常重要。
- 易于实验——我相信 Solr 在这方面是最好的。
- 与其他软件的接口 - Sphinx 与 MySQL 具有良好的接口。Solr 支持 ruby、XML 和 JSON 接口作为 RESTful 服务器。Lucene 只允许您通过 Java 进行编程访问。 罗盘 和 休眠搜索 是 Lucene 的包装器,将其集成到更大的框架中。
我们在垂直搜索项目中使用狮身人面像MySQL的记录10.000.000 +和10+不同的数据库。 它得到了MySQL和非常出色的支持对索引的高性能,研究是快,但也许比Lucene的少一点。 然而,它的,如果你需要快速索引每天使用MySQL数据库的正确选择。
我的sphinx.conf
source post_source
{
type = mysql
sql_host = localhost
sql_user = ***
sql_pass = ***
sql_db = ***
sql_port = 3306
sql_query_pre = SET NAMES utf8
# query before fetching rows to index
sql_query = SELECT *, id AS pid, CRC32(safetag) as safetag_crc32 FROM hb_posts
sql_attr_uint = pid
# pid (as 'sql_attr_uint') is necessary for sphinx
# this field must be unique
# that is why I like sphinx
# you can store custom string fields into indexes (memory) as well
sql_field_string = title
sql_field_string = slug
sql_field_string = content
sql_field_string = tags
sql_attr_uint = category
# integer fields must be defined as sql_attr_uint
sql_attr_timestamp = date
# timestamp fields must be defined as sql_attr_timestamp
sql_query_info_pre = SET NAMES utf8
# if you need unicode support for sql_field_string, you need to patch the source
# this param. is not supported natively
sql_query_info = SELECT * FROM my_posts WHERE id = $id
}
index posts
{
source = post_source
# source above
path = /var/data/posts
# index location
charset_type = utf-8
}
测试脚本:
<?php
require "sphinxapi.php";
$safetag = $_GET["my_post_slug"];
// $safetag = preg_replace("/[^a-z0-9\-_]/i", "", $safetag);
$conf = getMyConf();
$cl = New SphinxClient();
$cl->SetServer($conf["server"], $conf["port"]);
$cl->SetConnectTimeout($conf["timeout"]);
$cl->setMaxQueryTime($conf["max"]);
# set search params
$cl->SetMatchMode(SPH_MATCH_FULLSCAN);
$cl->SetArrayResult(TRUE);
$cl->setLimits(0, 1, 1);
# looking for the post (not searching a keyword)
$cl->SetFilter("safetag_crc32", array(crc32($safetag)));
# fetch results
$post = $cl->Query(null, "post_1");
echo "<pre>";
var_dump($post);
echo "</pre>";
exit("done");
?>
样品结果:
[array] =>
"id" => 123,
"title" => "My post title.",
"content" => "My <p>post</p> content.",
...
[ and other fields ]
斯芬克斯查询时间:
0.001 sec.
斯芬克斯查询时间(1K并发):
=> 0.346 sec. (average)
=> 0.340 sec. (average of last 10 query)
MySQL查询时间:
"SELECT * FROM hb_posts WHERE id = 123;"
=> 0.001 sec.
MySQL查询时间(1K并发):
"SELECT * FROM my_posts WHERE id = 123;"
=> 1.612 sec. (average)
=> 1.920 sec. (average of last 10 query)
唯一elasticsearch VS Solr的性能比较,我已经能够到目前为止发现是在这里:
Lucene是很好的和所有,但其停止词集是可怕的。我不得不手动添加一吨的停止的话StopAnalyzer.ENGLISH_STOP_WORDS_SET只是为了得到它附近的任何地方使用。
我没有使用过狮身人面像,但我知道人们通过它的速度誓与近神奇“易于安装,以迷死人”的比例。
尝试indextank。
作为弹性搜索的情况下,它被设想为更容易比的lucene / solr的使用。它还包括可以在不重新索引进行调整非常灵活的评分系统。