この質問は、あらゆる面で答えられるべき非常に広い答えを要求します。特別なユースケースでは、あるシステムを別のシステムよりも優れたものにする可能性のある特定の仕様が非常によくありますが、ここで基本を説明したいと思います。
ほぼ同じように機能するいくつかの検索エンジンの例として、Solrを完全に扱います。
いくつかの難しい事実から始めたいと思います：
-
安全なデータベースとしてSolr/Luceneを信頼することはできません。理由のリストがありますが、それらのほとんどは、リカバリオプションの欠落、酸トランザクションの欠如、複雑化の可能性などで構成されています。solrを使用する場合は、SQLテーブルなどの別のソースからインデックスを設定する必要があります。実際、solrは、複数のテーブルやリレーションからのデータを含むドキュメントを格納するのに最適です。そうしないと、複雑な結合を構築する必要があります。
-
Solr / Luceneは、驚異的なテキスト分析/ステミング/全文検索スコアリング/あいまいさ機能を提供します。 MySQLではできないこと。実際、MySqlでの全文検索はMyIsamに限定されており、スコアリングは非常に簡単で制限されています。フィールドの重み付け、特定のメトリックでのドキュメントのブースト、フレーズの近接性に基づくスコア結果、精度の一致などは、非常に困難であり、ほとんど不可能です。
-
Solr/Luceneにはドキュメントがあります。関係やプロセスを実際に保存することはできません。もちろん、あるドキュメントの複数値フィールド内で他のドキュメントのキーにインデックスを付けることができるので、この方法で実際に1：nリレーションを格納し、n：nを取得するために両方の方法を実行できますが、データのオーバーヘッドがあります。誤解しないでください。多くの目的で完全に細かく効率的です（たとえば、製品の販売業者を保管したい、特定の販売業者などで入手可能な部品のみを検索したい製品カタログの場合）。しかし、あなたはHAS /HASNOTで可能性の終わりに到達します。 「少なくとも3つのディストリビューターで入手可能なすべての製品を入手する」などのことはできません。
-
Solr / Luceneには、非常に優れたファセット機能と検索後分析があります。例：40000ヒットの非常に広範な検索の後、このフィールドにこの値を設定し、そのフィールドにその値を設定するように検索を絞り込んだ場合、3ヒットしか得られないことを表示できます。 MySQLで追加のクエリが必要な作業は、効率的かつ便利に実行されます。
まとめましょう
-
Luceneの力は、テキスト検索/分析です。また、逆インデックス構造のため、驚くほど高速です。あなたは本当にたくさんの後処理をすることができて、他のニーズを満たすことができます。ドキュメント指向であり、トリプルストアがSPARQLで行うような「グラフクエリ」はありませんが、基本的なN：Mリレーションを保存してクエリすることができます。アプリケーションがテキスト検索に重点を置いている場合、非常に複雑な多次元範囲フィルタークエリなどの正当な理由がない場合は、Solr/Luceneを選択する必要があります。
-
テキスト検索ではなく、ポイントアンドクリックでテキストを入力できないものがある場合は、古き良きリレーショナルデータベースがおそらくより良い方法です。