☰

データベースとしての NoSQL (MongoDB) と Lucene (または Solr) [closed] 質問する

tag-icon • tag-icon mongodb solr lucene memcached nosql
データベースとしての NoSQL (MongoDB) と Lucene (または Solr) [closed] 質問する

ドキュメントベースのデータベースに基づく NoSQL の動きが拡大する中、最近 MongoDB を調べました。アイテムを「ドキュメント」として扱う方法が、Lucene (および Solr のユーザー) と非常に似ていることに気付きました。

では、質問です。「データベース」として、Lucene (または Solr) ではなく NoSQL (MongoDB、Cassandra、CouchDB など) を使用する理由は何でしょうか?

私が（そして他の人も）答えに求めているのは、それらの詳細な比較です。リレーショナル データベースの議論は、目的が異なるため、ここでは省略します。

Lucene には、強力な検索や重み付けシステムなど、いくつかの大きな利点があります。Solr のファセットは言うまでもありません (Solr はまもなく Lucene に統合されます。やったー!)。Lucene ドキュメントを使用して ID を保存し、MongoDB のようにドキュメントにアクセスできます。これを Solr と組み合わせると、Web サービス ベースの負荷分散ソリューションが実現します。

MongoDB の同様のデータ保存とスケーラビリティについて話すときに、Velocity や MemCached などのアウトオブプロセス キャッシュ プロバイダーの比較も加えることができます。

MongoDB に関する制限は MemCached の使用を思い出させますが、Microsoft の Velocity を使用すれば、MongoDB よりもグループ化とリスト収集のパワーを強化できます (そう思います)。メモリにデータをキャッシュするよりも高速でスケーラブルな方法はありません。Lucene にもメモリ プロバイダーがあります。

MongoDB (およびその他) には、API の使いやすさなど、いくつかの利点があります。ドキュメントを新規作成し、ID を作成して保存します。完了です。とても簡単です。

ベストアンサー1

これは素晴らしい質問です。私もかなり考えてきたことです。私が学んだ教訓をまとめます。

  1. ほとんどすべての状況で、MongoDB の代わりに Lucene/Solr を簡単に使用できますが、その逆はできません。Grant Ingersoll の投稿にそのことがまとめられています。

  2. MongoDB などは、検索やファセット処理を必要としない用途に使用されているようです。RDBMS の世界から脱却しようとしているプログラマーにとっては、よりシンプルで、おそらく移行も容易なようです。慣れていないと、Lucene と Solr の学習曲線はより急峻です。

  3. Lucene/Solr をデータストアとして使用する例は多くありませんが、Guardian はある程度の進歩を遂げ、これを優れたスライド デッキにまとめています。ただし、彼らも Solr の流行に完全に飛びついて、Solr と CouchDB を組み合わせることを「調査」するかどうかについては明言していません。

  4. 最後に、私たちの経験を紹介しますが、残念ながらビジネス ケースについてはあまり明らかにできません。私たちは数 TB のデータ規模、ほぼリアルタイムのアプリケーションに取り組んでいます。さまざまな組み合わせを検討した後、Solr を使い続けることにしました。これまでのところ (6 か月と数ヶ月) 後悔はなく、他のものに切り替える理由も見当たりません。

要約: 検索要件がない場合、Mongo はシンプルで強力なアプローチを提供します。ただし、検索がサービス提供の鍵となる場合は、1 つの技術 (Solr/Lucene) に固執し、徹底的に最適化して可動部分を少なくする方がよいでしょう。

私の意見ですが、お役に立てれば幸いです。

おすすめ記事