Luceneについて誰かがチャイムを鳴らしているのを見るのは良いことです-それについては私にはわからないからです。
一方、スフィンクスはよく知っているので、何か助けになるかどうか見てみましょう。
- 結果の関連性ランキングがデフォルトです。必要に応じて独自の並べ替えを設定し、特定のフィールドに高い重みを付けることができます。
- データベースと直接通信するため、インデックス作成の速度は非常に高速です。速度の低下は、複雑なSQLクエリやインデックス付けされていない外部キーなどの問題が原因で発生します。検索の遅さに気づいたこともありません。
- 私はRailsの人なので、Djangoで実装するのがどれほど簡単かわかりません。ただし、Sphinxソースに付属しているPythonAPIがあります。
- 検索サービスデーモン（searchd）のメモリ使用量はかなり少なく、メモリ量 インデクサープロセスも使用します。
- スケーラビリティは私の知識がより大雑把なところですが、インデックスファイルを複数のマシンにコピーして複数の検索されたデーモンを実行するのは簡単です。しかし、他の人から得られる一般的な印象は、高負荷の下ではかなり良いということです。したがって、複数のマシンにスケールアウトすることは、対処する必要のあることではありません。
- 「did-you-mean」などはサポートされていませんが、他のツールを使用すれば簡単に実行できます。 Sphinxは辞書を使用しても語幹を使用するため、「運転」と「運転」（たとえば）は検索で同じと見なされます。
- Sphinxでは、フィールドデータの部分インデックスの更新は許可されていません。これに対する一般的なアプローチは、最近のすべての変更でデルタインデックスを維持し、変更のたびにこれを再インデックス化することです（これらの新しい結果は1〜2秒以内に表示されます）。データ量が少ないため、これには数秒かかる場合があります。ただし、メインデータセットのインデックスを定期的に再作成する必要があります（ただし、データの変動性にどの程度定期的に依存しますか？毎日？毎時？）。インデックス作成の速度が速いため、これはすべて非常に簡単です。
これがあなたの状況にどれほど当てはまるかはわかりませんが、 Evan Weaverは、いくつかの一般的なRails検索オプションを比較しました （Sphinx、Ferret（Ruby用のLuceneの移植版）およびSolr）、いくつかのベンチマークを実行しています。役に立つかもしれません。
MySQLの全文検索の深さについては詳しく説明していませんが、Sphinx、Lucene、Solrと速度的にも機能的にも競合しないことはわかっています。