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

私は現在、巨大なSQLクエリではなく、他の検索方法を検討しています。私が見たelasticsearch最近とで演奏ヒューという音（検索エンジンのPython実装）。

選択の理由を教えてください。

ElasticSearchの作成者として、私が先に進み、そもそもそれを作成した理由をいくつか説明できます:)。

純粋なLuceneの使用は困難です。本当にうまく機能させたい場合は注意が必要な点がたくさんあります。また、そのライブラリは分散サポートされていないため、維持する必要があるのは単なる組み込みJavaライブラリです。

Luceneのユーザビリティに関しては、（ほぼ6年後の）昔、コンパスを作成しました。その目的は、Luceneの使用を簡素化し、日常のLuceneをよりシンプルにすることでした。私が何度も何度も遭遇したのは、コンパスを配布できるようにするための要件です。コンパス内から、GigaSpaces、Coherence、Terracottaなどのデータグリッドソリューションと統合することで作業を開始しましたが、それだけでは十分ではありません。

基本的に、分散Luceneソリューションは分割する必要があります。また、ユビキタスAPIとしてのHTTPとJSONの進歩により、さまざまな言語のさまざまなシステムを簡単に使用できるソリューションが実現しました。

そのため、ElasticSearchを作成しました。非常に高度な分散モデルがあり、JSONをネイティブに話し、JSON DSLを介してシームレスに表現される多くの高度な検索機能を公開します。

Solrは、HTTPを介してインデックス作成/検索サーバーを公開するためのソリューションでもありますが、ElasticSearchは、はるかに優れた分散モデルと使いやすさを提供します（現時点では一部の検索機能が欠けていますが、長くはありません場合、計画はすべてのコンパス機能をElasticSearchに取り込むことです）。もちろん、ElasticSearchを作成して以来、偏見があるので、自分で確認する必要があるかもしれません。

Sphinxは使ったことがないのでコメントできません。私が言及できるのは、Sphinxフォーラムのこのスレッドです。ElasticSearchの優れた分散モデルを証明していると思います。

もちろん、ElasticSearchには、単に配布されるだけでなく、さらに多くの機能があります。実際にはクラウドを念頭に置いて構築されています。機能一覧はサイトでご確認いただけます。

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

単純な全文検索の設定だけが必要な場合は、Sphinxが適しています。

検索をまったくカスタマイズしたい場合は、ElasticsearchとSolrの方が適しています。これらは非常に拡張可能です。独自のプラグインを作成して結果のスコアを調整できます。

いくつかの使用例：

• Sphinx：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には1つありますが、他については知りません。
• 実装言語の習熟度-Javaを知らない場合は、Java Luceneに触れないでください。Sphinxを使用するには、C ++が必要になる場合があります。Luceneは他の 言語にも移植されています。これは、検索エンジンを拡張する場合に最も重要です。
• 実験のしやすさ-この点でSolrが最適だと思います。
• 他のソフトウェアとのインターフェース-SphinxはMySQLとの良好なインターフェースを備えています。Solrは、RESTfulサーバーとしてルビー、XML、およびJSONインターフェースをサポートしています。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
}

テストスクリプト：

<?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 ]

Sphinxクエリ時間：

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)

これまでに見つけた唯一のelasticsearch対solrパフォーマンスの比較はここにあります：

Solr対elasticsearch Deathmatch！

Luceneは素晴らしいですが、そのストップワードセットはひどいものです。StopAnalyzer.ENGLISH_STOP_WORDS_SETに使用可能な大量のストップワードを手動で追加して、使用可能な近くに配置する必要がありました。

私はSphinxを使用していませんが、その速度とほぼ魔法のような「セットアップのしやすさからすごい」比率で人々が誓うことを知っています。

インデックスタンクをお試しください。

エラスティックサーチの場合と同様に、lucene / solrよりもはるかに使いやすいと考えられています。また、インデックスを再作成せずに微調整できる非常に柔軟なスコアリングシステムも含まれています。