26

何百万ものドキュメントを MongoDB に保存することを計画しており、全文検索が非常に必要です。Elasticsearch と Solr が全文検索に最適なソリューションであると読みました。

  • エラスティック検索は、Mongodb の全文検索に使用できるほど成熟していますか? コレクションのシャーディングも行っています。Elasticsearch はシャード コレクションで動作しますか?

  • Elasticsearch または Solr を使用する利点と欠点は何ですか?

  • MongoDB は全文検索を実行できますか?

4

7 に答える 7

25

MongoDB にはいくつかの検索機能がありますが、検索エンジンほど機能が豊富ではありません。

http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo

Mongo と Solr を使用して、コンテンツを検索可能にしています。私たちが Solr を好む理由は

  • 構成とカスタマイズが簡単です
  • 大規模なコミュニティがあります (オープンソース ツールを使用している場合、これは非常に役立ちます)

私たちは ES と一緒に仕事をしていなかったので、それについて多くを語ることはできませんでした。以下のリンクで、Solr と ES に関する議論を見つけることができます。

于 2012-06-13T14:50:19.597 に答える
22

Solr/MySQL と ElasticSearch/MongoDB の両方で専門的な経験があります。

検索エンジンに多くのクエリを実行する場合は、MongoDB を既にシャーディングしています (つまり、検索エンジンもシャーディングしたい場合): やりたいことが ElasticSearch で実行できない場合を除き、ElasticSearch を使用する必要があります。 . また、シャードしない場合でも使用する必要があります。

ElasticSearch は、分散環境と検索に慣れている誰かからシャーディング メカニズムをもたらす Lucene の上に新しいプロジェクトです (Shay Bannon は Compass を作成し、データグリッド エディターである Gigaspaces で働いていました)。

ElasticSearch は MongoDB と同じくらい簡単にシャード化できますが、それはさらに簡単で、ほとんどの場合、デフォルトでうまく機能すると思います。

Solrはあまり好きではありません。

  • クエリ言語はまったく構造化されていません (ただし、プラグインと Lucene の場合であり、この非構造化クエリ言語を ES でも使用できると思います)。
  • 適切な Solr クライアントはないと思います。Solr Java クライアントは最悪です。PHP の人たちも不満を言っているのを耳にしますが、ElasticSearch Java クライアントは非常に優れており、タイプセーフであり、非同期サポートを提供します (たとえば、Netty を使用している場合は優れています)。Solr では、多くの文字列連結を行います。
  • スケーリングしにくい
  • それほど新しいプロジェクトではありませんが、技術部門を持っていることを感じました。ElasticSearch は Compass から生まれたので、すべての技術部門が削除され、新鮮な新しいアプローチが採用されたと思います。

データのインポートに関しては、Solr DataImportHandler と ElasticSearch リバー (CouchDB と MongoDB) の両方の経験があります。私が言えることは：

  • Solr はより多くのことを可能にしますが、非常に構造化されていない XML の方法であり、ドキュメントは、ハローの世界から出て高度な機能を使用しようとすると、実際に何が起こっているのかを理解するのにあまり役立ちません。
  • ElasticSearch アプローチはよりシンプルで制限もありますが、一部のテクノロジをすぐにサポートしていますが、DataImportHandler はより複雑な SQL に適しているようです。
  • 私の Solr プロジェクトでは、一部のドキュメントに対して手動のインデックス作成を使用する必要がありましたが、それは主に、必要なデータをドキュメントに非正規化できないことが原因でした (Solr プロジェクトでは MySQL を使用しています)。

Solr と ElasticSearch の両方に対応する新しい MongoDB コネクタもあります。これを早急にテストする必要があります:) http://blog.mongodb.org/post/29127828146/introducing-mongo-connector

最終的に、私は間違いなく ElasticSearch を選択します。理由は次のとおりです。

  • 今では素晴らしいコミュニティがあります
  • ElasticSearch のように Solr を使用した経験のある多くの人を知っています。
  • クライアント側はより安全で構造化されており、Java Futures との非同期を提供します
  • どちらも、おそらく新しいコネクタを使用して MongoDB から簡単にデータをインポートできます
  • 私の知る限り、Solr が行うほとんどすべてのことを実行できます (私の経験では、私は検索エンジンの専門家ではありません)。
  • それは箱から出してシャーディングを追加します
  • リアルタイムでスケーラブルなアプリケーションを構築するのに役立つパーコレーションを追加します (ただし、おそらく追加のメッセージング テクノロジが必要になります)。
  • 私が読んだソース コードには、Solr に比べて (少なくともクライアント側では) 技術的な部分がほとんどなく、プラグインを作成するのも簡単に思えます。
于 2013-01-01T23:09:11.037 に答える
7

ネイティブの MongoDB に関しては、全文検索をサポートしていません。これは人気のある機能リクエストであることがわかります。

https://jira.mongodb.org/browse/SERVER-380

MongoDB の ES リバー プラグインについて私が知っていることから、それはその機能の oplog を追跡します。シャードされたセットアップには複数の oplog があり、mongos 経由で接続するようにそのコードを簡単に変更する方法がないためです。

同様に、Solr についても、私が見た例は通常、ES プラグインと同様の動作を伴います。ここにいくつかのより確かな情報があります：

http://blog.knuthaugen.no/2010/04/cooking-with-mongodb-and-solr.html

私はこれを使用した経験はありませんが、他の人が以前に比較したことがあります。こちらをご覧ください。

Solr と ElasticSearch の比較

ElasticSearch、Sphinx、Lucene、Solr、Xapian。どの用途にどれが合う？

于 2012-06-13T14:02:14.823 に答える
6

MongoDB は効率的な全文検索を行うことができません。フィールドでワイルドカード検索を実行できますが、これらはインデックスを効率的に使用しているとは思いません。

ElasticSearchのリバー機能を使用して、ドキュメントを MongoDB から ElasticSearch に自動的にプッシュすることをお勧めします。

elasticsearch-river-mongodbは、MongoDB から Elasticsearch へのリバーであり、MongoDB でドキュメントが変更されると、ElasticSearch は oplog を監視し、そのインデックスを自動的に更新します。

ElasticSearch は Mongo のレプリケーション テーブルを監視しているだけなので、これにより 2 つのデータストアの同期を維持する問題が最小限に抑えられます。

于 2012-08-17T15:45:20.357 に答える
2

Mongo は全文検索には適していません。明らかに、高速検索のためにフィールドにインデックスを付ける必要があり、BIG データ (長い長い文字列) を含むフィールドのインデックス作成は mongo では失敗します。インデックスには 1k の制限があります。1k を超えるコンテンツがある場合、インデックスによって無視され、検索結果に表示されません。明らかに、記事の全文検索を実行しようとしている場合、mongo は良い選択ではありません。

于 2012-12-07T15:06:18.237 に答える