0

さまざまなデータを含む多くのテーブルを持つかなり大きなデータベースを構築しています。

ただし、各テーブルには、ビデオ タイトルやトラック タイトルなど、同様のフィールドがあります。

今私が直面している問題は、5 つ以上のテーブルでキーワードの一致を探すクエリを作成する方法です。各テーブルには 10 万行から 100 万行、場合によっては数百万行が含まれる可能性があることに注意してください。

テーブルごとに結合または個別のクエリを使用すると非常に遅くなると思うので、検索データを格納する別のテーブルを 1 つ作成することを考えました。

たとえば、次のようなフィールドを持つことができると思います。

id ---- username ---- title ---- body ---- date ---- belongs_to ---- post_id

このようにして、検索がはるかに高速になると思いますか、それとも完全に間違っていますか?

私が考えることができるこのアプローチの唯一の問題は、テーブルの一部から元のレコードが削除された場合、「検索」テーブルからもレコードを削除する必要があるため、このテーブルを管理するのが難しいことです。

4

2 に答える 2

0

多数のテーブルを結合するために MySQL を使用しないでください。RDBMS を使用した Apache Solr を検討することをお勧めます

于 2013-08-14T23:14:43.343 に答える
0

いくつかの情報検索システムを見てみましょう。また、独自のインデックスも必要であるため、検索インデックスを最新の状態に保つために、更新のたびに (または定期的に) データにインデックスを付ける必要があります。ただし、次の利点があります。

  • 特にその目的のために設計された特別なアルゴリズムとデータ構造を使用するため、はるかに高速です
  • 一連の用語に基づいてドキュメントを検索する機能 (および場合によっては、結果に表示されてはならない一連の否定的な用語も)
  • フレーズの検索 (つまり、特定の順序で次々に出現する用語)
  • 自動ステミング (つまり、"s"、"ed"、"ing" などの単語の語尾を取り除きます ...)
  • スペルミスの検出 (つまり、「もしかして...?」)
  • 非常に一般的な無意味な単語 (「a」、「the」など) のインデックス作成を避けるためのストップワード
  • ワイルドカード クエリ
  • 高度なランキング戦略 (つまり、検索用語の出現回数と位置に基づいて、関連性でランク付けします)

私は過去に自分のプロジェクトでxapianを使用したことがありますが、非常に満足しています。LuceneSolr、およびエラスティック検索は、ニーズに合う可能性のある他の非常に人気のあるプロジェクトです。

于 2013-08-14T23:56:10.423 に答える