更新
質問の範囲が修正されたので、この点でも何かを追加するかもしれません。
Apache Solr と ElasticSearch には多くの比較がありますので、私は自分が最も役立つと思うもの、つまり最も重要な側面をカバーするものを参照します：
Bob Yoplaitはすでにkimchyの答えを ElasticSearch、Sphinx、Lucene、Solr、Xapianにリンクしています。どちらの用途に適していますか？ は、彼が先に進んで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組織 に応じて、もう適用されません。そもそもかなり活発なコミッターベースを持っています]自動加温機能はありません[新しい インデックスウォームアップAPI ]
初期回答
これらは完全に異なるユースケースに対処する完全に異なるテクノロジーであるため、意味のある方法で比較することはできません。
Apache Solr -Apache Solrは、使いやすい高速なsearch serverで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はSolrSolrで対処するのが難しい（より）現代のクラウド環境におけるスケーラビリティ要件の欠点。
そのため、おそらくElasticSearchと最近導入されたAmazon CloudSearchを比較するのが最も便利でしょう（紹介記事 原則として両方が同じユースケースをカバーすると主張しているため、1時間で100ドル未満/月で検索を開始してください ）。
私は上記の答えのいくつかが今少し時代遅れになっているのを見ます。私の視点から見て、私はSolr（クラウドと非クラウド）とElasticSearchの両方を日常的に使用していますが、興味深い違いがいくつかあります。
- コミュニティ：Solrは、より大きく、より成熟したユーザ、開発者、そして貢献者コミュニティを持っています。 ESには、小規模だが活発なユーザーコミュニティと、成長を続ける貢献者コミュニティがあります。
- 成熟度：Solrはもっと成熟していますが、ESは急速に成長しており、安定していると思います
- パフォーマンス：判断が難しい。直接的なパフォーマンスベンチマークは行っていません。 LinkedInの人は、SolrとESとSenseiを一度比較しましたが、SolrとESの両方に専門家ではない設定を使用したため、最初の結果は無視してください。
- デザイン：人々はSolrが大好きです。 Java APIはやや冗長ですが、まとめ方が好きな人もいます。 Solrコードは残念ながらいつもとてもきれいというわけではありません。また、ESには、分割機能、リアルタイムの複製機能、ドキュメントおよびルーティング機能が組み込まれています。これのいくつかはSolrにもありますが、それはちょっとした事後思考のようです。
- サポート：SolrとElasticSearchの両方に技術サポートとコンサルティングサポートを提供している会社があります。私は両方をサポートしている唯一の会社はSematextだと思います（開示：私はSematextの創設者です）
- スケーラビリティ：両方とも非常に大きなクラスタに拡張できます。 ESは、Solr 4.0より前のバージョンのSolrよりも拡張が簡単ですが、Solr 4.0ではそうではありません。
Solr vs. ElasticSearchトピックのより完全な報道については https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ をご覧ください。これは、Sematextによる直接的および中立的なSolr対ElasticSearchの比較に関する一連の記事の最初の記事です。開示：私はSematextで働いています。
ElasticSearch対Solrの質問には、機能や機能の面で多くの人が回答していますが、パフォーマンスの面で比較する方法については、ここ（または他の部分）ではあまり議論しません。
だから私は自分で 調査 を行うことにしました。私はすでに用語検索にSolrを使用している、すでにコード化された異種データソースのマイクロサービスを利用しました。 Solr for ElasticSearchをオフにしてから、すでにコーディング済みの負荷テストアプリケーションを使用してAWSで両方のバージョンを実行し、その後の分析のためにパフォーマンスメトリクスをキャプチャしました。
これが私が見つけたものです。 ElasticSearchは、ドキュメントのインデックス作成時のスループットが13％向上しましたが、Solrは10倍高速でした。文書の照会に関しては、SolrはElasticSearchよりも5倍のスループットと5倍の速さを持っていました。
Apache Solrの長い歴史から、Solrの1つの強みは エコシステム だと思います。さまざまな種類のデータや目的のための多くのSolrプラグインがあります。
下から上に向かって次の層で検索プラットフォーム：
- データ
- 目的：さまざまなデータ型と情報源を表す
- 文書作成
- 目的：索引付け用の文書情報を作成する
- 索引付けと検索
- 目的：文書索引を作成して照会する
- 論理強化
- 目的：検索クエリと結果を処理するための追加ロジック
- 検索プラットフォームサービス
- 目的：サービスプラットフォームを提供するために検索エンジンコアの追加機能を追加します。
- UIアプリケーション
- 目的：エンドユーザー検索インターフェースまたはアプリケーション
参考記事： エンタープライズサーチ
私は、.NETアプリケーションのsolr検索とelastic検索の両方に取り組んできました。私が直面している主な違いは
エラスティック検索：
- より多くのコードとより少ない設定、しかし変更するAPIがありますが、それでもコード変更です
- 複合型の場合、型内の型、つまりネストした型（solrでは実現できませんでした）
Solr：
- より少ないコードとより多くの設定、そしてそれ故により少ないメンテナンス
- クエリ中に結果をグループ化するための方法（簡単な方法ではなくエラスティック検索で達成するための多くの作業）
ElasticsearchとSolrおよびsplunkの主な違いの表を作成しました。2016年の更新版として使用できます： 
過去15年間、さまざまなLucene検索エンジンに「公開」されていた言語学者として、上記のリンクはすべてメリットがあり、過去に大きな利益をもたらしてきましたが、私はPythonの弾力検索開発は非常に速いと言えます。そうは言っても、コードの中には直感的に理解できないものもあります。そこで、私はオープンソースの観点からELKスタックの1つのコンポーネントであるKibanaに手を差し伸べ、Kibanaで非常に簡単にelasticsearchのコードを生成できることを知りました。また、Chrome Sense esクエリをKibanaにも取り込むことができます。あなたがesを評価するためにKibanaを使うなら、それはあなたの評価をさらにスピードアップするでしょう。他のプラットフォームで実行するのに何時間もかかったのは、最短で数分で最大のデータセットでelasticsearch（RESTfulインターフェース）の上にあるJSON in Senseで稼働することでした。せいぜい数秒で。 elasticsearchのドキュメンテーションは、700ページ以上ありますが、通常はSOLRや他のLuceneのドキュメンテーションで解決されるであろう質問に答えていませんでした。また、エラスティック検索での集約を見てみるとよいでしょう。これはFacetingを新しいレベルに引き上げました。
全体像：データサイエンス、テキスト分析、または計算言語学を行っている場合、elasticsearchには情報検索分野で革新的なランキングアルゴリズムがいくつかあります。 TF/IDFアルゴリズム、テキスト頻度/逆文書頻度を使用している場合、elasticsearchはこの1960年代のアルゴリズムを、BM25、Best Match 25、およびその他の関連性ランキングアルゴリズムを使用しても新しいレベルに拡張します。そのため、単語、フレーズ、文をスコア付けまたはランク付けする場合は、他のデータ分析アプローチによる数時間かかる大きなオーバーヘッドなしに、elasticsearchはこのスコア付けをその場で行います。特に、集約によるバケット化の長所とリアルタイムのJSONデータ関連性のスコア付けおよびランク付けを組み合わせることで、アジャイル（ストーリー）またはアーキテクチャー（ユースケース）のいずれかのアプローチに応じて、優れた組み合わせを見つけることができます。
注：上記の集計についても同様の議論がありましたが、集計や関連性スコアについては説明していません。重複があることをお詫び申し上げます。ディスクロージャー：私はelasticsearchを使って慈善事業をしない限り、私はelasticのために働いていないし、異なる建築上の道のために近い将来彼らの優れた作品から利益を得ることができないでしょう。
ユースケースを想像してみてください。
- 多数（100+）の小さい（10Mb-100Mb、1000-100000文書）検索索引。
- 彼らは多くのアプリケーション（マイクロサービス）で使用されています
- 各アプリケーションは複数のインデックスを使用できます
- サイズ指数で小さい、はい。しかし、非常に大きな負荷（毎秒数百の検索要求）と要求は複雑です（複数の集約、条件など）。
- ダウンタイムは許可されていません
- そのすべてが長年働いていて、絶えず成長しています。
各インデックスごとに個別のESインスタンスを持つというアイデアは、この場合、大きなオーバーヘッドです。
私の経験によると、この種のユースケースはElasticsearchでサポートするのが非常に複雑です。
どうして？
最初。
主な問題は基本的な後方互換性が無視されることです。
画期的な変更はとてもクールです！ （注：アップグレード時にすべてのSQLステートメントを少し変更する必要があるSQLサーバーを想像してみてください。想像することはできません。しかし、ESでは通常のことです）
次のメジャーリリースで削除される予定の非推奨はとてもセクシーです。 （注：ご存じのとおり、Javaには20年以上前の廃止予定がいくつかありますが、それでも実際のJavaバージョンでは機能しています...）
それだけでなく、時々あなたはどこにも文書化されていない何かを持っている（個人的には一度だけ遭遇したが...）
そう。あなたがESをアップグレードしたいのであれば（あなたが何らかのアプリに新しい機能を必要としたりバグ修正を受けたいから） - あなたは地獄にいます。それがメジャーバージョンのアップグレードに関するものであればなおさらです。
クライアントAPIは後方互換性がありません。インデックス設定は後方互換性がありません。そしてESアップグレードですべてのアプリ/サービスを同時にアップグレードするのは現実的ではありません。
しかし、あなたはそれを時々しなければなりません。他に方法はありません。
既存のインデックスは自動的にアップグレードされますか？ - はい。しかし、古いインデックスの設定を変更する必要があるときには役に立ちません。
それに耐えるためには、あなたは絶えず多くの力に投資する必要があります...将来のESのリリースとあなたのアプリ/サービスの前方互換性。あるいは、アプリ/サービスとESの間に何らかの互換性のあるクライアントAPIを提供するミドルウェアを構築する必要があります。 （そして、あなたはTransport Clientを使うことができません（それはすべてのマイナーバージョンESアップグレードのためにjarアップグレードを必要としたので）、そしてこの事実はあなたの人生を楽にしません）
それはシンプル＆安いですか？いいえ、ちがいます。それからは程遠い。 ESに基づいた複雑なインフラストラクチャの継続的なメンテナンスは、あらゆる意味でコストのかかる方法です。
2回目。単純なAPI？うーん、違います。本当に複雑な条件や集約を使っている場合.... 5つの入れ子になったレベルを持つJSONリクエストはどんなものでも、単純ではありません。
残念ながら、私はSOLRについての経験がなく、それについて何も言うことができません。
しかし、Sphinxsearchは完全に後方互換性のあるSphinxQLであるため、このシナリオよりはるかに優れています。
注意：Sphinxsearch/Manticoreは本当に興味深いです。それはLucineベースではありません、そして結果として真剣に異なります。 ESが持っていないボックスからのいくつかのユニークな機能を含み、小/中サイズのインデックスでは頭がおかしくなります。
私は3年間Elasticsearchを使い、1か月ほどSolrを使いましたが、Solrをインストールするのに比べてelasticsearchクラスタをインストールするのはとても簡単だと思います。 Elasticsearchには、説明が豊富なヘルプ文書が多数あります。ユースケースの1つは私がESで利用可能だったがSolrで見つけられなかったヒストグラム集約で立ち往生していました。
あなたがすでにSOLRを使っているのなら、それを守ってください。起動している場合は、Elastic検索に進みます。
最大の主要な問題はSOLRで修正されており、それは非常に成熟しています。
私はElastic-searchだけを使います。私はsolrを始めるのが非常に難しいことがわかったので。 Elastic-searchの機能：
- 始めるのは簡単、非常に少ない設定。初心者でも段階的にクラスタを設定できます。
- NoSQLクエリを使用したシンプルなRestful API。そして簡単にアクセスするための多くの言語ライブラリ。
- 良い文書、あなたはその本を読むことができます：。公式サイトにWeb版があります。
入れ子になった文書をsolrに追加すると非常に複雑になり、入れ子になったデータ検索も非常に複雑になります。 Elastic Searchは入れ子になった文書を追加して検索するのが簡単です