759

これらのテクノロジーの主なアーキテクチャ上の違いは何ですか?

また、一般的にそれぞれに適したユースケースは何ですか?

4

12 に答える 12

572

アップデート

質問の範囲が修正されたので、これに関しても何か追加するかもしれません。

利用可能なApache SolrとElasticSearchの比較は多数あるので、私が最も役立つと思ったものを参照します。つまり、最も重要な側面をカバーします。

  • Bob Yoplait はすでに、kimchy の回答をElasticSearch、Sphinx、Lucene、Solr、Xapian にリンクしています。どの用途にどれが合う？これは、彼が先に進んで ElasticSearch を作成した理由をまとめたものです。ElasticSearchは、彼の意見では、 Solr と比較してはるかに優れた分散モデルと使いやすさを提供します。

  • Ryan Sonnek のRealtime Search: Solr vs Elasticsearchは洞察力に富んだ分析/比較を提供し、Solr から ElasticSeach に切り替えた理由を説明しています。彼はすでに満足している Solr ユーザーですが、これを次のように要約しています。

    Solrは、標準的な検索アプリケーションを構築する際の最適な武器かもしれませんが、Elasticsearchは、最新のリアルタイム検索アプリケーションを作成するためのアーキテクチャを使用して、Solr を次のレベルに引き上げ ます。パーコレーションは、Solr を水面から吹き飛ばすエキサイティングで革新的な機能です。Elasticsearch はスケーラブルでスピーディーで、 との統合が夢のようです。Adios Solr、あなたと知り合えてよかった。[鉱山を強調]

  • ElasticSearch に関するウィキペディアの記事では、評判の高いドイツの iX マガジンからの比較を引用し、長所と短所をリストしています。

    利点:

    • ElasticSearch が配布されています。個別のプロジェクトは必要ありません。レプリカもほぼリアルタイムで、「プッシュ レプリケーション」と呼ばれます。
    • ElasticSearch は、Apache Lucene のほぼリアルタイムの検索を完全にサポートしています。
    • マルチテナンシーの処理は特別な構成ではなく、Solr ではより高度なセットアップが必要です。
    • ElasticSearch はゲートウェイの概念を導入し、完全バックアップを容易にします。

    短所:

    • 主要な開発者は 1 人のみ[現在の Elasticsearch GitHub 組織によると、適用されなくなりました。そもそも、かなり活発なコミッター ベースが存在します]
    • 自動ウォーミング機能なし[新しい Index Warmup APIに従って適用されなくなりました]

最初の回答

これらはまったく異なるユースケースに対応するまったく異なるテクノロジーであるため、意味のある方法で比較することはできません。

  • Apache Solr - Apache Solr は、ファセット、スケーラビリティなどの追加機能を備えた、使いやすく高速な検索サーバーで Lucene の機能を提供します。

  • Amazon ElastiCache - Amazon ElastiCache は、クラウド内のインメモリ キャッシュのデプロイ、操作、スケーリングを容易にするウェブ サービスです。

    • Amazon ElastiCacheは、広く採用されているメモリ オブジェクト キャッシング システムである Memcached のプロトコルに準拠しているため、既存の Memcached 環境で現在使用しているコード、アプリケーション、および一般的なツールは、サービスとシームレスに連携することに注意してください (詳細については、 Memcachedを参照してください)。

[鉱山を強調]

おそらく、これは次の 2 つの関連するテクノロジと何らかの形で混同されている可能性があります。

  • ElasticSearch - Apache Lucene の上に構築された、オープン ソース (Apache 2) の分散型 RESTful 検索エンジンです。

  • Amazon CloudSearch - Amazon CloudSearch は、クラウド内の完全マネージド型の検索サービスであり、高速で高度にスケーラブルな検索機能をアプリケーションに簡単に統合できます。

SolrとElasticSearchのオファリングは一見非常に似ているように見えますが、どちらも同じバックエンド検索エンジン、つまりApache Luceneを使用しています。

Solrは古く、非常に用途が広く、成熟しており、それに応じて広く使用されていますが、ElasticSearchは、 Solrで対処するのが難しい最新のクラウド環境でのスケーラビリティ要件に関するSolrの欠点に対処するために特別に開発されました。

そのため、 ElasticSearchと最近導入されたAmazon CloudSearchを比較するのがおそらく最も役立つでしょう(紹介記事「月額 100 ドル未満で 1 時間で検索を開始する」を参照)。どちらも原則として同じユースケースをカバーすると主張しているからです。

于 2012-04-18T16:15:50.433 に答える
210

上記の回答のいくつかは、現在は少し古くなっています。私の観点から言えば、私は Solr (クラウドと非クラウド) と ElasticSearch の両方を日常的に使用しています。興味深い違いがいくつかあります。

  • コミュニティ: Solr には、より大規模で成熟したユーザー、開発者、および貢献者のコミュニティがあります。ES には、小さいながらも活発なユーザー コミュニティと、成長している貢献者のコミュニティがあります。
  • 成熟度: Solr はより成熟していますが、ES は急速に成長しており、安定していると思います
  • 性能：判断が難しい。私/私たちは、直接的なパフォーマンス ベンチマークを行っていません。LinkedIn の担当者は、Solr と ES と Sensei を 1 回比較しましたが、Solr と ES の両方に専門家以外の設定を使用したため、最初の結果は無視する必要があります。
  • デザイン: 人々は Solr を愛しています。Java API はいくぶん冗長ですが、人々はそれがどのようにまとめられているかを気に入っています。残念ながら、Solr のコードは必ずしもきれいなわけではありません。また、ES には、シャーディング、リアルタイム レプリケーション、ドキュメント、およびルーティングが組み込まれています。これの一部は Solr にも存在しますが、後付けのように感じます。
  • サポート: Solr と ElasticSearch の両方の技術サポートとコンサルティング サポートを提供する企業があります。両方をサポートしている会社は Sematext だけだと思います (開示: 私は Sematext の創設者です)。
  • スケーラビリティ: どちらも非常に大きなクラスターにスケーリングできます。ES は、Solr 4.0 以前のバージョンの Solr よりもスケーリングが容易ですが、Solr 4.0 ではそうではなくなりました。

Solr と ElasticSearch のトピックの詳細については、https: //sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ を参照してください。これは、直接的かつ中立的な Solr と ElasticSearch の比較を行う Sematext からの一連の投稿の最初の投稿です。開示：私はSematextで働いています。

于 2012-08-26T15:02:22.173 に答える
18

Apache Solr の歴史は長いので、Solr の強みの 1 つはそのエコシステムにあると思います。さまざまな種類のデータと目的に対応する多数の Solr プラグインがあります。

ソルスタック

下から上に次のレイヤーでプラットフォームを検索します。

  • データ
    • 目的: さまざまなデータ タイプとソースを表す
  • ドキュメント構築
    • 目的: 索引付けのための文書情報を作成する
  • 索引付けと検索
    • 目的: ドキュメント インデックスの作成とクエリ
  • ロジック強化
    • 目的: 検索クエリと結果を処理するための追加ロジック
  • 検索プラットフォーム サービス
    • 目的: サービス プラットフォームを提供するために、検索エンジン コアの機能を追加します。
  • UI アプリケーション
    • 目的: エンドユーザー検索インターフェースまたはアプリケーション

参考記事：エンタープライズサーチ

于 2016-11-11T16:23:24.520 に答える
8

上記のリンクにはすべてメリットがあり、過去 15 年間さまざまな Lucene 検索エンジンに「さらされた」言語学者として、私は過去に大きな恩恵を受けてきましたが、Python ではエラスティック検索の開発が非常に高速であると言わざるを得ません。そうは言っても、一部のコードは直感的ではないと感じました。そこで、オープンソースの観点から ELK スタックの 1 つのコンポーネントである Kibana にアクセスしたところ、Kibana で Elasticsearch のやや不可解なコードを非常に簡単に生成できることがわかりました。また、Chrome Sense のクエリを Kibana にプルすることもできました。Kibana を使用して es を評価すると、さらに評価が高速化されます。他のプラットフォームで実行するのに何時間もかかったものは、elasticsearch (RESTful インターフェイス) 上の JSON in Sense で、最悪の場合 (最大のデータ セット) で数分で実行されました。せいぜい数秒で。Elasticsearch のドキュメントは 700 ページ以上ありますが、通常は SOLR や他の Lucene ドキュメントで解決されるはずの質問に答えていませんでした。明らかに分析に時間がかかりました。また、ファセットを新しいレベルに引き上げたエラスティック検索の集計を確認することもできます。

全体像: データ サイエンス、テキスト分析、または計算言語学を行っている場合、elasticsearch には、情報検索分野でうまく革新しているように見えるいくつかのランキング アルゴリズムがあります。TF/IDF アルゴリズム、テキスト頻度/逆ドキュメント頻度を使用している場合、elasticsearch は、BM25、ベスト マッチ 25、およびその他の関連性ランキング アルゴリズムを使用しても、この 1960 年代のアルゴリズムを新しいレベルに拡張します。したがって、単語、フレーズ、または文をスコアリングまたはランク付けする場合、elasticsearch はこのスコアリングをオンザフライで行います。数時間かかる他のデータ分析アプローチの大きなオーバーヘッドはなく、elasticsearch のもう 1 つの時間節約になります。es を使用すると、集計からのバケット化のいくつかの利点と、リアルタイムの JSON データ関連性スコアリングおよびランキングを組み合わせることで、優れた組み合わせを見つけることができます。

注：上記の集計に関する同様の議論を見ましたが、集計と関連性スコアリングについては見ませんでした-重複についてお詫びします. 開示：私はelasticのために働いておらず、elasticsearchで慈善活動をしない限り、別のアーキテクチャパスのために、近い将来彼らの優れた仕事から利益を得ることができません。これは悪い考えではありません.

于 2016-02-03T00:04:48.177 に答える
6

すでに SOLR を使用している場合は、そのまま使用してください。起動している場合は、エラスティック検索に進みます。

SOLR では最大の主要な問題が修正されており、かなり成熟しています。

于 2016-08-25T11:54:07.087 に答える