Solr対ElasticSearch [終了]

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

また、一般的にどのユースケースがそれぞれに適していますか？

更新

質問のスコープが修正されたので、この点についても追加します。

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

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

• Ryan Sonnekのリアルタイム検索：SolrとElasticsearchは洞察に満ちた分析/比較を提供し、Solrユーザーとしてすでに満足しているにもかかわらず、SolrからElasticSeachに切り替えた理由を説明しています。

  標準の検索アプリケーションを構築する場合、Solrが最適な武器になる可能性がありますが、Elasticsearchは、最新のリアルタイム検索アプリケーションを作成するためのアーキテクチャーにより、それを次のレベルに引き上げ ます。パーコレーションはエキサイティングで革新的な機能であり、独力でSolrを水から吹き飛ばします。Elasticsearchはスケーラブルでスピーディーで、と統合する夢です。Adios Solr、あなたを知ってよかったです。【重点鉱山】

• ElasticSearchに関するWikipediaの記事は、評判の高いドイツのiXマガジンの比較を引用しており、利点と欠点をリストしています。

  利点：

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

  短所：

  • 主な開発者は1人だけです [現在のelasticsearch GitHub組織によれば、そもそもかなりアクティブなコミッターベースがあることに加えて、もう適用されません]
  • 自動ウォーミング機能はありません [新しいIndex Warmup APIにより、適用されなくなりました]

最初の回答

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

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

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

  • ことをしてください、ノート、サービスとシームレスに連携します既存のMemcachedの環境に今日使用することをアマゾンElastiCacheは、Memcachedのとプロトコルに準拠しており、広く採用されているメモリオブジェクトキャッシュシステムなので、コード、アプリケーション、および一般的なツール（参照Memcachedの詳細については）。

【重点鉱山】

たぶん、これは次の2つの関連テクノロジーと何らかの方法で混同されています。

• ElasticSearchは - それは、オープンソース（Apacheの2）である、分散、RESTfulな、検索エンジンは、Apache Luceneの上に構築されました。

• Amazon CloudSearch - Amazon CloudSearchは、クラウド内の完全に管理された検索サービスであり、これを使用すると、高速で拡張性の高い検索機能をアプリケーションに簡単に統合できます。

SolrのとElasticSearch製品は一見著しく類似音、両方が同じバックエンド検索エンジン、すなわち使用のApache Luceneのを。

一方でSolrには非常に汎用性の高い、古いと成熟し、広く応じて使用し、ElasticSearchはアドレスに特別に開発されたのSolrとのアドレスへ（ER）困難な近代的なクラウド環境でのスケーラビリティ要件と欠点のSolr。

そのため、どちらも原則として同じユースケースをカバーしていると主張しているため、ElasticSearchと最近導入されたAmazon CloudSearchを比較することはおそらく最も有用です（紹介投稿「1時間で$ 100 /月未満で検索を開始する」を参照）。

上記の回答の一部は少し古くなっているようです。私の観点から、私はSolr（クラウドと非クラウド）とElasticSearchの両方を日常的に使用していますが、興味深い違いがいくつかあります。

• コミュニティー：Solrには、より大きく、より成熟したユーザー、開発者、および貢献者のコミュニティーがあります。ESのユーザーコミュニティは小さくてもアクティブですが、貢献者のコミュニティが拡大しています
• 成熟度：Solrはより成熟していますが、ESは急速に成長しており、安定していると思います
• パフォーマンス：判断が難しい。私/私たちは直接的なパフォーマンスのベンチマークを行っていません。LinkedInの人がSolrとESを比較したのは一度だけでしたが、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からの一連の投稿の最初の投稿です。情報開示：私はセマテキストで働いています。

ここの多くの人々が、機能と機能の点でこのElasticSearch対Solrの質問に答えたことがわかりますが、パフォーマンスの点でどのように比較するかについて、ここ（または他の場所）であまり議論していません。

そのため、自分で調査することにしました。私は、用語の検索にSolrをすでに使用している、コーディング済みの異種データソースマイクロサービスを利用しました。Solr for ElasticSearchを切り替えた後、すでにコード化された負荷テストアプリケーションを使用してAWSで両方のバージョンを実行し、その後の分析のためにパフォーマンスメトリックをキャプチャしました。

これが私が見つけたものです。ElasticSearchは、ドキュメントのインデックス作成に関して13％高いスループットを実現しましたが、Solrは10倍高速でした。ドキュメントのクエリに関しては、Solrのスループットは5倍で、ElasticSearchの5倍の速さでした。

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

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

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

参照記事：エンタープライズ検索

elasticsearchとSolrおよびsplunkの主な違いの表を作成しました。2016年の更新として使用できます。

私は.NetアプリケーションのSolrとElastic Searchの両方に取り組んできました。私が直面した主な違いは

弾性検索：

• より多くのコードと少ない設定、ただし変更するAPIがありますが、それでもコードの変更です
• 複合型の場合、型内の型、つまりネストされた型（solrでは実現できませんでした）

Solr：

• より少ないコードとより多くの設定、それゆえより少ないメンテナンス
• クエリ中に結果をグループ化するため（簡単な方法で弾性検索で達成する多くの作業）

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

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

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

ユースケースを想像してください：

1. 大量（100+）の小さな（10Mb-100Mb、1000-100000ドキュメント）検索インデックス。
2. 多くのアプリケーション（マイクロサービス）で使用している
3. 各アプリケーションは複数のインデックスを使用できます
4. はい、サイズインデックスで小さいです。しかし、巨大な負荷（1秒あたり数百の検索要求）と要求は複雑です（複数の集計、条件など）
5. ダウンタイムは許可されていません
6. そのすべてが何年も働いており、常に成長しています。

各インデックスごとに個別のESインスタンスを作成するという考えは、この場合大きなオーバーヘッドです。

私の経験では、この種のユースケースはElasticsearchでサポートするには非常に複雑です。

どうして？

最初。

主な問題は、基本的な後方互換性の無視です。

重大な変更はとてもクールです！（注：アップグレード時にすべてのSQLステートメントを少し変更する必要があるSQLサーバーを想像してください...想像できません。ただし、ESの場合は通常です）

次のメジャーリリースで廃止される非推奨はとてもセクシーです！（注：ご存知のとおり、Javaには20年以上前の非推奨がいくつか含まれていますが、実際のJavaバージョンではまだ機能しています...）

それだけでなく、どこにも文書化されていないものがある場合もあります（個人的に一度だけ遭遇しましたが...）

そう。ESをアップグレードする場合（一部のアプリに新機能が必要な場合、またはバグ修正を取得したい場合）-あなたは地獄にいます。特にそれがメジャーバージョンのアップグレードについてである場合。

クライアントAPIは下位互換性がありません。インデックス設定には互換性がありません。また、ESアップグレードですべてのアプリ/サービスを同時にアップグレードすることは現実的ではありません。

しかし、あなたは時々それをしなければなりません。他に方法はありません。

既存のインデックスは自動的にアップグレードされますか？- はい。ただし、いくつかの古いインデックス設定を変更する必要がある場合には役立ちません。

それと共存するには、ESの将来のリリースでのアプリ/サービスの上位互換性に常に多くの力を投資する必要があります。または、アプリ/サービスとESの間に、互換性のあるクライアントAPIを提供するある種のミドルウェアを構築する（そして常にサポートする）必要があります。（そして、トランスポートクライアントを使用することはできません（マイナーバージョンESのアップグレードごとにjarのアップグレードが必要なため）。これにより、作業が楽になるわけではありません）

シンプルで安く見えますか？いいえ、ちがいます。それから遠い。ESに基づく複雑なインフラストラクチャの継続的なメンテナンスは、あらゆる意味で高額になる方法です。

セカンド。シンプルなAPI？ええと...いいえ。実際に複雑な条件と集計を使用している場合... 5つのネストされたレベルを持つJSONリクエストは何でも簡単です。

残念ながら、私はSOLRの経験がなく、何も言えません。

しかし、Sphinxsearchは、完全に後方互換性のあるSphinxQLであるため、このシナリオよりもはるかに優れています。

注：Sphinxsearch / Manticoreは本当に興味深いものです。Lucineベースではないため、結果は大きく異なります。ESにはないボックスからのいくつかのユニークな機能が含まれており、小/中サイズのインデックスで非常に高速です。

すでにSOLRを使用している場合は、そのまま使用してください。起動している場合は、Elastic searchにアクセスしてください。

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

Elasticsearchを3年間使用し、Solrを約1か月使用しています。elasticsearchクラスターは、Solrのインストールと比較して非常に簡単にインストールできます。Elasticsearchには、説明が豊富なヘルプドキュメントのプールがあります。ESで利用可能でSolrにはないヒストグラム集約に悩まされていたユースケースの1つ。

Elastic-searchのみを使用しています。私はsolrを始めるのが非常に難しいことを発見したので。Elastic-searchの機能：

1. 簡単に設定でき、設定はほとんどありません。初心者でも、段階的にクラスターをセットアップできます。
2. NoSQLクエリを使用するシンプルなRESTful API。簡単にアクセスできる多くの言語ライブラリ。
3. 良いドキュメントです。本を読むことができます：。公式サイトにウェブ版があります。

入れ子になったドキュメントをsolrに非常に複雑に追加し、入れ子になったデータ検索も非常に複雑にします。しかし、Elastic Searchはネストされたドキュメントの追加と検索が簡単です