[解決済み】データベースとしてのNoSQL（MongoDB） vs Lucene（またはSolr）【クローズド

質問

ドキュメントベースのデータベースをベースにしたNoSQLの動きが活発になってきているので、最近MongoDBを見てみました。 Luceneがやっているように（そしてSolrのユーザーも）、アイテムを"Documents"として扱う方法に著しい類似性があることに気づきました。

そこで、質問です。 なぜ、Lucene（またはSolr）ではなくNoSQL（MongoDB、Cassandra、CouchDBなど）をquot;database"として使用したいのですか？

私が（そして他の人もそうだと思いますが）答えを求めているのは、それらを深く掘り下げて比較することです。 リレーショナル・データベースの議論は、目的が異なるので、すべてスキップしてしまいましょう。

Luceneは、強力な検索システムやウェイトシステムなど、いくつかの重大な利点を提供します。 Solrのファセットは言うまでもありません（SolrはもうすぐLuceneに統合されます、イェーイ！）。 LuceneのドキュメントをIDの保存に使用し、MongoDBのようにドキュメントにアクセスすることができます。 Solrと組み合わせれば、Webサービスベースの負荷分散ソリューションが完成します。

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

MongoDB周りの制約を見るとMemCachedを使うことを思い出すが、MicrosoftのVelocityを使えばMongoDBよりもグルーピングやリスト収集の力がある（と思う）。 メモリにデータをキャッシュする以上の速度とスケーラビリティは得られない。 Luceneにだってメモリプロバイダはあるんだし。

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

どのように解決するのですか？

これは素晴らしい質問で、私もずいぶん考えさせられました。私が学んだことをまとめます。

1. MongoDBの代わりにLucene/Solrを使うことは、ほとんどすべての場面で簡単にできますが、その逆はできません。グラント・インガーソルの の記事でまとめています。

2. MongoDBなどは、検索やファセットを必要としない用途に使えるようです。RDBMSの世界から脱却したプログラマーにとっては、よりシンプルで間違いなく移行しやすいと思われる。LuceneやSolrは、慣れていない限り、学習曲線が急です。

3. Lucene/Solrをデータストアとして使用する例はあまり多くありませんが、Guardianがいくつか前進しており、これをまとめた素晴らしい記事があります。 スライドデッキ しかし、彼らはあまりにも完全にSolrの流行に飛び乗ると＆quot;調査＆quot;SolrとCouchDBを組み合わせる上で非妥協的である。

4. 最後に、私たちの経験をお話します。残念ながら、ビジネスケースについて多くを明らかにすることはできません。私たちは、数TBのデータを扱う、ほぼリアルタイムのアプリケーションです。様々な組み合わせを調査した結果、Solrにこだわることにしました。これまでのところ（6ヶ月間）後悔はしていませんし、他に乗り換える理由もないと思っています。

まとめ：検索を必要としない場合、Mongoはシンプルかつパワフルなアプローチを提供します。しかし、検索が重要であれば、1つの技術(Solr/Lucene)にこだわり、それを最適化したほうがよいでしょう - 可動部品が少ないので。

私の2セントがお役に立てれば幸いです。