データベースとしてのNoSQL（MongoDB）とLucene（またはSolr）

ドキュメントベースのデータベースに基づいて成長するNoSQLの動きに伴い、最近、MongoDBを検討しました。Lucene（およびSolrのユーザー）と同様に、アイテムを「ドキュメント」として扱う方法との驚くべき類似性に気づきました。

それで、質問：Lucene（またはSolr）よりもNoSQL（MongoDB、Cassandra、CouchDBなど）を「データベース」として使用する理由は何ですか？

私が（そして他の人も確実に）答えを探しているのは、それらのいくつかの詳細な比較です。リレーショナルデータベースのディスカッションは、目的が異なるため、まとめてスキップしてみましょう。

Luceneには、強力な検索や重み付けシステムなど、いくつかの深刻な利点があります。Solrのファセットは言うまでもありません（SolrはすぐにLuceneに統合されます、そうです！）。Luceneドキュメントを使用してIDを保存し、MongoDBと同じようにドキュメントにアクセスできます。それをSolrと組み合わせると、WebServiceベースの負荷分散ソリューションが得られます。

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

MongoDBに関する制限はMemCachedの使用を思い出させますが、MicrosoftのVelocityを使用して、MongoDBよりもグループ化とリスト収集の機能を強化できます（私はそう思います）。メモリにデータをキャッシュするよりも高速またはスケーラブルなものを取得できません。Luceneにもメモリプロバイダーがあります。

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

これは素晴らしい質問です。私はかなり考えました。私が学んだ私の教訓を要約します：

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）にこだわり、その中から最適化することをお勧めします。可動部品の数は少なくなります。

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

Solrでドキュメントを部分的に更新することはできません。ドキュメントを更新するには、すべてのフィールドを再投稿する必要があります。

そしてパフォーマンスが重要です。コミットしないと、solrへの変更は有効になりません。毎回コミットすると、パフォーマンスが低下します。

solrにはトランザクションはありません。

solrにはこれらの欠点があるため、nosqlの方が適している場合があります。

MongoDBとSolrを一緒に使用すると、パフォーマンスが向上します。あなたは私を見つけることができ、ここでブログの記事を、私たちは一緒にこの技術を使用する方法を説明したところ。ここに抜粋があります：

[...]ただし、インデックスサイズが増加すると、Solrのクエリパフォーマンスが低下することがわかります。最善の解決策はSolrとMongo DBの両方を一緒に使用することであることがわかりました。次に、コンテンツをMongoDBに格納し、Solrを使用して全文検索用のインデックスを作成することにより、SolrをMongoDBと統合します。各ドキュメントの一意のIDをSolrインデックスに格納し、Solrで検索した後、MongoDBから実際のコンテンツを取得するだけです。アナライザーやスコアリングなどがないため、MongoDBからのドキュメントの取得はSolrよりも高速です。[...]

また、一部の人々はSolrにすべてのインデックスを保存し、oplog操作を監視し、関連する更新をSolrにカスケードすることにより、Solr / LuceneをMongoに統合していることに注意してください。

このハイブリッドアプローチを使用すると、フルテキスト検索や高速書き込みなどの機能を備え、信頼性の高いデータストアで書き込み速度を飛躍的に向上させることができるため、両方の利点を最大限に活用できます。

セットアップは少し技術的ですが、solrに統合できるoplogテーラーがたくさんあります。この記事でrangespanが行ったことを確認してください。

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

私の両方の経験から、Mongoはシンプルで簡単な使い方に最適です。私たちが苦しんでいる主なMongoの欠点は、予期しないクエリのパフォーマンスが低いことです（可能なすべてのフィルター/並べ替えの組み合わせに対してmongoインデックスを作成することはできず、単純にできません）。

そしてここLucene / Solrが特にFilterQueryキャッシングで大きな成功を収めているところでは、パフォーマンスは卓越しています。

他の誰もそれを言及しなかったので、Solrがスキーマを実施するのに対して、MongoDBはスキーマレスであることを付け加えておきます。したがって、ドキュメントのフィールドが変更される可能性が高い場合、それがSolrよりもMongoDBを選択する理由の1つです。

@ mauricio-schefferがSolr 4について言及しました-そのことに興味がある人のために、LucidWorksはSolr 4を「NoSQL検索サーバー」と説明しており、http：//www.lucidworks.com/webinar-solr-4-the-nosqlにビデオがあります。 -search-server /では、NoSQL（ish）機能について詳しく説明しています。（-ishは、実際には動的スキーマであるschemalessのバージョン用です。）

キーと値の形式を使用してデータを保存するだけの場合は、逆索引がディスク領域を無駄に消費するため、Luceneはお勧めできません。また、ディスクにデータを保存すると、redisはRAMにデータを保存するため、redisなどのNoSQLデータベースよりもパフォーマンスが大幅に低下します。Luceneの最大の利点は、多くのクエリをサポートするため、あいまいなクエリをサポートできることです。

mongo op-log tailのようなサードパーティのソリューションは魅力的です。開発/アーキテクチャの観点から、ソリューションを緊密に統合できるかどうかについて、いくつかの考えや質問が残っています。いくつかの理由により、これらの機能の緊密に統合されたソリューションが見られるとは期待していません（多少推測的であり、明確化の対象であり、開発努力が最新ではありません）。

• mongoはc ++、lucene / solrはjava
  • 多分luceneはいくつかのモンゴライブラリを使用することができます
  • たぶんmongoはいくつかのluceneアルゴリズムを書き直すことができます、以下も参照してください：
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• luceneはさまざまなドキュメント形式をサポートしています
  • mongoはJSON（BSON）に焦点を当てています
• luceneは不変のドキュメントを使用します
  • 利用可能な場合、単一フィールドの更新が問題になります
• luceneインデックスは複雑なマージ操作で不変です
• mongoクエリはJavaScriptです
• mongoにはテキストアナラ​​イザー/トークナイザー（AFAIK）はありません
• mongo docのサイズは限られているため、ルセンに関しては穀物に反する可能性があります
• mongoアグリゲーションopsがluceneに配置されていない可能性があります
  • luceneには、ドキュメント間でフィールドを保存するオプションがありますが、それは同じではありません
  • solrは何らかの形で集計/統計とSQL /グラフクエリを提供します

MongoDB Atlasには、luceneベースの検索エンジンがまもなく登場します。今週のMongoDB World 2019カンファレンスで大きな発表がありました。これは、高収益のMongoDB Atlas製品の使用を促進する優れた方法です。

MongoDB Enterpriseバージョン4.2に組み込まれることを期待していましたが、オンプレミス製品ラインに導入されたというニュースはありませんでした。

詳細はこちら：https : //www.mongodb.com/atlas/full-text-search