ElasticSearch、Sphinx、Lucene、Solr、Xapian。どれがどの用途に適していますか?[閉まっている]

StackOverflow https://stackoverflow.com/questions/2271600

質問

現在、巨大な SQL クエリではなく、他の検索方法を検討しています。私が見た 弾性検索 最近一緒に遊んだ シューッという音 (検索エンジンの Python 実装)。

選んだ理由を教えていただけますか?

役に立ちましたか？

解決

ElasticSearchの作成者として、多分私はあなたに私が先に行って、最初の場所でそれを作成した理由について、いくつかの推論を与えることができます：。）

純粋なのLuceneを使用することは困難です。多くのあなたはそれが本当によく実行したい場合のために世話をするために必要なもの、そしてまた、そのライブラリは、そう、それはあなたが維持するために必要なだけの組み込みJavaライブラリ一切分担支持ません、があります。

のLucene使いやすさの面では、帰り（ほぼ6年になりました）、私はコンパスを作成したとき。その目的は、Luceneのを使用して簡素化し、日常のLucene簡単にするためでした。私は再び時間と時間に出くわしたことはコンパスが配布していることができるようにするための要件です。私はGigaSpaces、コヒーレンス、およびテラコッタなどのデータグリッド・ソリューションとの統合により、コンパスの中から、それに取り組み始めたが、それは十分ではありません。

は、その中核に、分散Luceneの溶液をかけらにする必要があります。また、ユビキタスなAPIとしてHTTPやJSONの進歩と、それは、異なる言語の多くの異なるシステムを容易に使用することができる溶液を意味する。

私は先に行って、ElasticSearchを作成した理由です。それは、非常に高度な分散モデルを持っているネイティブJSONを話すと、多くの高度な検索機能、シームレスにJSONのDSLで表現すべてを公開します。

Solrには、HTTP経由インデックス/検索サーバーを露出させるための解決策ですが、私は ElasticSearch のことを主張するだろう（現在、検索機能の一部に欠けているものの、しかし長くはないため、いずれの場合には、計画では、のコンパスのElasticSearchに備えて、すべてを取得することです）の使用の多くの優れた分散モデルと使いやすさを提供します。もちろん、私はあなたがあなた自身のためにチェックする必要がある場合がありますので、私は、ElasticSearchを作成するので、バイアスされています。

スフィンクスのためとして、私はそれを使用していないので、私はコメントすることはできません。私が参照することができますあなたは何を私が証明していると思うスフィンクスフォーラムの時にこのスレッドrel="noreferrer"> href="http://sphinxsearch.com/forum/view.html?id=5118"を

もちろん、ElasticSearchだけ配布されるよりも多くの機能を備えています。これは、実際には心の中で、クラウドで構築されています。あなたは、サイト上の機能リストを確認することができます。

他のヒント

Sphinx、Solr、Elasticsearch を使用しました。Solr/Elasticsearch は Lucene 上に構築されています。多くの一般的な機能が追加されます。WebサーバーAPI、ファセット、キャッシュなど。

シンプルな全文検索の設定だけを行いたい場合は、Sphinx の方が良い選択です。

検索を少しでもカスタマイズしたい場合は、Elasticsearch と Solr を選択することをお勧めします。これらは非常に拡張性があります。独自のプラグインを作成して結果のスコアを調整できます。

いくつかの使用例:

  • スフィンクス：クレイグリスト.org
  • ソル:Cnet、Netflix、digg.com
  • エラスティックサーチ:Foursquare、Github

ルーセンを定期的に使用して、数千万のドキュメントをインデックス付けおよび検索しています。検索は十分に速く、長い時間はかからないインクリメンタルアップデートを使用します。ここに来るのに時間がかかりました。ルーセンの強みは、そのスケーラビリティ、幅広い機能、開発者のアクティブなコミュニティです。Bare Luceneを使用するには、Javaでのプログラミングが必要です。

新たに始める場合、Lucene ファミリーのツールは次のとおりです。 ソルル, これは、裸の Lucene よりもセットアップがはるかに簡単で、Lucene のほぼすべての機能を備えています。データベースドキュメントを簡単にインポートできます。Solr は Java で書かれているため、Solr を変更するには Java の知識が必要ですが、構成ファイルを調整するだけで多くのことが可能になります。

また、特に MySQL データベースと組み合わせた Sphinx についても良いことを聞いています。使ったことはありませんが。

IMO、次に従って選択する必要があります。

  • 必要な機能 - 例:フランス語のステマーが必要ですか?Lucene と Solr には 1 つありますが、他のものについては知りません。
  • 実装言語の熟練度 - Java を知らない場合は、Java Lucene に触れないでください。Sphinx を使用するには C++ が必要になる場合があります。Lucene も移植されています 他の 言語. 。これは、検索エンジンを拡張する場合に最も重要です。
  • 実験のしやすさ - この点では Solr が最適だと思います。
  • 他のソフトウェアとのインターフェース - Sphinx は MySQL との優れたインターフェースを備えています。Solr は、RESTful サーバーとして Ruby、XML、および JSON インターフェイスをサポートします。Lucene では、Java を介したプログラムによるアクセスのみが可能です。 方位磁針 そして 休止状態の検索 Lucene をより大きなフレームワークに統合するラッパーです。

私たちは、MySQLのレコード10.000.000 +と垂直検索プロジェクトにスフィンクスを使用して10+別のデータベース。 これは、MySQLのための非常に優れたサポートと索引に高いパフォーマンスを持っている、研究は速いが、おそらくLuceneのより少し小さいです。 あなたはすぐに毎日のインデックス作成とMySQL DBを使用する必要がある場合はそれが正しい選択だ。

href="http://karussell.wordpress.com/2011/05/12/elasticsearch-vs-solr-lucene"をのElasticSearchとSolrのを比較rel="noreferrer"> / P>

私の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)

私がこれまでに見つけることができましたSolrの性能比較対のみelasticsearchがここにあります：

Solrのelasticsearchのデスマッチ対！の

のLuceneは素晴らしく、すべてのですが、そのストップワードセットがひどいです。私は手動でどこでも使えるの近くにそれを得るためにStopAnalyzer.ENGLISH_STOP_WORDS_SETにストップワードのトンを追加する必要がありました。

比率私はスフィンクスを使用していないが、私は人々がその速度とほぼ魔法「素晴らしさに設定のしやすさ」によって誓う知っています。

indextankしてみます。

弾性検索の場合としては、Luceneと/ Solrに比べてより使いやすくなるように考案されました。また、インデックスの再作成せずに微調整することができる非常に柔軟なスコアリングシステムを備えている。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top