2012-04-19 12 views
0

MySQL 5.5.22の複数のテーブルで全文検索を実行しています。このアプリケーションでは、innodbテーブルを使用しているので、フルテキスト検索専用のMyISAMテーブルをいくつか作成しました。例えば多くのテーブルでMySQLの全文検索で最も関連性の高い結果を集計

これらのテーブルは、全文検索のためだけであるため、私のテーブルのいくつかは

account_search 
=========== 
id 
account_id 
name 
description 
hobbies 
interests 

product_search 
=========== 
id 
product_id 
name 
type 
description 
reviews 

ようになり、それらが非正規化されています。データは複数のテーブルから取得でき、検索テーブルに集約されます。 ID列のほかに、残りの列は1つの全文索引に割り当てられます。

全文検索で「50%」ルールを回避するには、IN BOOLEAN MODEを使用しています。

したがって、上記のために、私が実行します:

SELECT *, MATCH(name, type, description, reviews) AGAINST('john') as relevance 
FROM product_search 
WHERE MATCH(name, type, description, reviews) AGAINST('john*' IN BOOLEAN MODE) LIMIT 10 

SELECT *, MATCH(name, description, hobbies, interests) AGAINST('john') as relevance 
FROM account_search 
WHERE MATCH(name, description, hobbies, interests) AGAINST('john*' IN BOOLEAN MODE) LIMIT 10 

のは、ちょうど私達が同様に「ジョン」と呼ばれる製品を持っていると仮定しましょう:P

私が直面しています問題は、次のとおりです。

  • 意味のある関連性を得るには、IN BOOLEAN MODEを付けずに検索する必要があります。これは、検索が50%の規則と語長の規則に従うことを意味します。したがって、多くの場合、product_searchテーブル内のほとんどの製品がjohnと呼ばれると、その関連性は0として返されます。

  • 複数のクエリ間の関連性は比較できません。 (私はある質問からの14の関連性は、別の異なる質問からの14の関連性に等しくないと思う)。

  • 検索はちょうどこれらの2つのテーブルに限定されるものではなく、例えば、他の「オブジェクトタイプ」、があります。「注文」、「取引」などが

私ができるようにしたいと思いますキーワードセット(1つの検索ボックスはALLオブジェクトの結果を返します)を指定して、すべてのオブジェクトタイプの上位7つの最も関連性の高い結果を返します。

上記のことから、トップ7を得るためのアルゴリズムや、さらに優れたアイデアは何ですか?

私はsolrやelasticsearchのようなものを使うことができますが、私はすでにそれらを試してみましたが、それらをアプリケーションに統合する手続きをしていますが、MySQLにしかアクセスできない人の検索を提供できるようにしたいと思います。

答えて

0

これについてしばらく考えてから、MySQL内で1つのクエリで関連性のランク付けを行う必要があると判断しました。別々のクエリの間の関連性を比較することができない

  • :ので

    です。

  • 複数の検索の内容を意味のある方法で組み合わせることは難しいです。

検索専用のインデックステーブルを使用するように切り替えました。エントリは、innodbテーブル内の実際の基礎となるデータの挿入、削除、更新に応じて挿入、削除、更新されます(これはすべて自動です)。

search 
============== 
id //id for the entry 
type //the table the data came from 
column //column the data came from 
type_id //id of the row the in the original table 
content //text 

コンテンツ列にフルテキストインデックスがあります:

テーブルは次のようになります。すべてのテーブルのすべてのカラムがインデックスに登録されるわけではなく、検索に役立つと思われるものだけが追加されていることを認識することが重要です。

このように、照会を実行してcontentに一致させ、私たちが持っているものを取り出してさらに処理します。最終的な結果を処理するには、親テーブルに検索結果のタイトルとその他のメタデータを要求するためにさらにクエリを実行する必要がありますが、これは実行可能なソリューションです。

このアプローチは実際にはスケールされません(更新と挿入にはこのテーブルも更新する必要があります)。しかし、アプリケーションの小規模な展開に対して適切なアプリケーション幅の検索を提供するのはかなり良い方法だと思います。

スケーラビリティのために、弾性検索、solrまたはluceneのようなものを使用してください。

関連する問題