新しいプロジェクトでは、サーチャーの実装に lucene を多用する必要があります。このサーチャーは、プロジェクトの非常に重要な (そして大きな) 要素になります。Relational Database + Lucene をMongoDbに置き換えるのは有効または便利ですか?
編集:わかりました、明確にします:私はリスクについて尋ねているのではなく、このプロジェクトでその代償を払うことができます。私のポイントは次のとおりです。MongoDB はこの種のことを指向していますか? Lucene と同じパフォーマンスの完全な検索エンジンを作成できますか? 友人は代替として MongoDB を指摘してくれましたが、Lucene のパフォーマンスがドキュメントの代替に付属しているかどうかはわかりません (そして、MongoDB でも見られます)、逆インデックスと最適化が完全に行われています。ドキュメントの向きに依存しません。
技術的には、MongoDB で全文検索を実行できますが、全文検索プロバイダーが提供する多くの機能を利用できません。私は MongoDB が大好きですが、実装までの時間が少しでも気になる場合は、MongoDB を全文検索プロバイダー (Lucene や Sphinx など) と組み合わせます。単語配列にインデックスを付けるという MongoDB の便利な機能は、全文検索よりもタグ付けとタグ付けに基づく検索に任せたほうがよいと思います。
検索 (情報検索) は、一致するドキュメントを取得するだけではありません。検索結果に関連性を持たせたい場合は、TF-IDF、フレーズ マッチング (シーケンス内の単語) に沿った何かが必要になります。より高いスコア) または検索精度を向上させるためのその他の IR 手法をいくつでも使用できます。MongoDB を使用する場合は、すべてをゼロから実装する必要があります。
本当にゼロからすべてを実装したいが、生のストレージ側に煩わされたくない場合、MongoDB は、それを上に実装できる最良の DB ストアにかなり近いものです (他に多くは考えられません)。それでも素晴らしい選択肢にはなりません。
CouchDbは、 couchdb-luceneプロジェクトを介して Lucene を使用 する (他の) 可能な代替手段のようです。
ルックは可能ですが、遅くなります (こちらを参照)
MongoDb は NOSQl、Lucene と SOLR は検索エンジンです。比較にもう 1 つ追加するのは、Terracota のようなキャッシュと EhCache です。すべてに独自の目的があります。
ステミングで全文検索と一緒に検索する必要がある場合、説明のテキスト マッチングよりも商品タイトル ランキングのテキスト マッチングで結果を表示するなどの関連性設定、および多くのそのようなテキスト ベースの機能。また、ランキング、関連性、同音一致、部分単語一致など。これらすべては、SOLR や Lucene などの検索ベースのストレージ システムで処理するのが最適です。
基準がより高速な検索のみであり、プレゼンテーション データ オブジェクトを永続的にする必要がない場合は、単純に Terracota のようなキャッシュを使用します。
より高速な取得が必要であり、1 つのデータソースでデータを連携して集約する必要があり、その集約されたデータの耐久性も必要な場合は、Mongodb のような NOSQL を使用してください。
もう 1 つのオプションは、elasticsearch (lucene でサポートされている) 幅のカウチデータベースを使用することです: http://www.elasticsearch.org/blog/2010/09/28/the_river_searchable_couchdb.html
私は MongoDB に詳しくないので、質問に直接答えることはできませんが、Lucene (約 10 年前) やリレーショナル データベース (数十年前から存在する) とは異なり、MongoDB は 3 年未満であることに注意したいと思います。年。
ゲームのこの段階では、まだ成熟している可能性があります。それはあなたのニーズに適しているかもしれません（そして、それを使用することに精通している人がここでチャイムを鳴らすかどうか知りたいです）が、これをあなたの方程式に組み込む必要があります. 最先端のテクノロジーを使用するために代償を払っても構わないと思っていますか?
十分に安定して効率的になったとしても、Web サイトやチュートリアルなどの形でサポートが制限されているという問題が発生する可能性があります (ユーザー ベースが小さいため)。また、廃止される可能性もあります。
このチャンスをつかむ価値はありますが、目を開けて、「ああ、ピカピカの新しいおもちゃを見て」という効果に目がくらむ必要はありません。
Lucene は確立された安定した製品です。残念ながら、MongoDB についてはまだ同じことが当てはまりません。したがって、Lucene と RDBMS の組み合わせは、リスクの少ない選択肢だと思います。
もちろん、ある程度はプロジェクトの性質にもよります。「非常に重要な (そして大きい)」とはどの程度重要なのでしょうか? もう 1 つは、MongoDB の経験はありますか (私はそうではないと思います)。ある程度の専門知識を持っている人にアクセスできれば、リスクが軽減されます。
Devoxx 2011 に参加し、10Gen のプレゼンテーションに参加した後、MongoDB と RDBMS データベースを比較する短いブログを書きました。MongoDB は人気のある Nosql データベースの 1 つです。MongoDB は NoSQL データベースであり、既存の主流の rdbms データベースとは異なります。
全文検索ソリューションについては、Lucene と Sphinx を以前に使用しましたが、提供されたキーワードに最適な結果を取得するにはあまり適していません。そこで、mongodb 全文検索プラグイン MongoLantern を使用しました。これは非常に優れています。また、性能面ではバックエンドエンジンにMongoDBを使用しているため、性能面での不具合は一切ありません。MongoLantern の製品の使いやすさに関して、さらなるレビューを待っています。
いいえ、違います。MongoDB はリレーショナルではないからです。