我目前正在寻找其他搜索方法,而不是拥有一个巨大的SQL查询.我最近看到了弹性搜索并玩弄了嗖嗖(搜索引擎的Python实现).
你能说出你的选择理由吗？
作为ElasticSearch的创建者,也许我可以给你一些推理,为什么我继续创建它并在第一时间创建它:).
使用纯Lucene具有挑战性.如果你希望它真正表现良好,你需要注意很多事情,还有它的库,所以没有分布式支持,它只是你需要维护的嵌入式Java库.
就Lucene的可用性而言,(当时差不多6年),我创建了Compass.它的目的是简化Lucene的使用,使每天的Lucene更简单.我一次又一次遇到的是要求能够分发Compass.我开始从Compass内部开始研究,通过与GigaSpaces,Coherence和Terracotta等数据网格解决方案集成,但这还不够.
其核心是分布式Lucene解决方案需要进行分片.此外,随着HTTP和JSON作为无处不在的API的发展,它意味着可以轻松使用具有不同语言的许多不同系统的解决方案.
这就是我继续创建ElasticSearch的原因.它具有非常先进的分布式模型,本地使用JSON,并且公开了许多高级搜索功能,所有功能都通过JSON DSL无缝表达.
Solr也是一个通过HTTP公开索引/搜索服务器的解决方案,但我认为ElasticSearch提供了一个更优越的分布式模型和易用性(虽然目前缺少一些搜索功能,但不是很长,而且在任何例如,计划是将所有Compass功能都纳入ElasticSearch).当然,我有偏见,因为我创建了ElasticSearch,所以你可能需要自己检查一下.
至于狮身人面像,我没有用它,所以我无法发表评论.我可以推荐你的是Sphinx论坛上的这个主题,我认为它证明了ElasticSearch的优秀分布式模型.
当然,ElasticSearch除了分发之外还有许多其他功能.它实际上是以云计算而构建的.您可以查看网站上的功能列表.
我使用过Sphinx,Solr和Elasticsearch.Solr/Elasticsearch建立在Lucene之上.它增加了许多常用功能:Web服务器api,faceting,缓存等.
如果您想要一个简单的全文搜索设置,Sphinx是一个更好的选择.
如果您想自定义搜索,Elasticsearch和Solr是更好的选择.它们非常易于扩展:您可以编写自己的插件来调整结果评分.
一些示例用法:
狮身人面像:craigslist.org
Solr:Cnet,Netflix,digg.com
Elasticsearch:Foursquare,Github
我们定期使用Lucene来索引和搜索数以千万计的文档.搜索速度很快,我们使用不需要很长时间的增量更新.我们花了一些时间来到这里.Lucene的优势在于其可扩展性,大量功能以及活跃的开发人员社区.使用裸Lucene需要用Java编程.
如果你重新开始,Lucene系列中的工具就是Solr,它比裸露的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为您提供编程访问.Compass和Hibernate Search是Lucene的包装器,它将它集成到更大的框架中.
我们在垂直搜索项目中使用Sphinx,其中包含10.000.000+的MySql记录和10多个不同的数据库.它对MySQL有很好的支持和索引的高性能,研究速度快但可能比Lucene少一点.但是,如果您需要每天快速编制索引并使用MySQL数据库,那么它是正确的选择.
比较ElasticSearch和Solr的实验
我的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
}
测试脚本:
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 "";
var_dump($post);
echo "";
exit("done");
?>
样本结果:
[array] => "id" => 123, "title" => "My post title.", "content" => "Mypost
content.", ... [ and other fields ]
狮身人面像查询时间:
0.001 sec.
Sphinx查询时间(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)
到目前为止我能找到的唯一弹性搜索与solr性能比较是:
Solr vs elasticsearch Deathmatch!
Lucene很好,但他们的停止词设置很糟糕.我不得不手动向StopAnalyzer.ENGLISH_STOP_WORDS_SET添加大量停用词,以使其接近可用.
我没有使用过Sphinx,但我知道人们发誓它的速度和近乎神奇的"易于设置到令人敬畏"的比例.
尝试indextank.
作为弹性搜索的情况,它被认为比lucene/solr更容易使用.它还包括非常灵活的评分系统,无需重新索引即可进行调整.
京公网安备 11010802040832号 | 京ICP备19059560号-6 