2011-01-29 11 views
5

私は大量のクエリを持っており、levenshteinを使ってタイプミスを計算しています。これで、levenshteinはmysqlに完全なCPU時間を要するようになりました。 私のクエリは、UNION文の全文検索+ levenshteinです。 sql1は現在のクエリですが、sql2は高速で完全なテキスト検索で、CPU時間が多すぎます。最後の1つはピークになるleventheinです。levenshteinの代替

あなたはどちらかといえば、入力ミスを防ぐ方法がありますか? ノーマライズデータには回答しないでください。私は考えましたが、データには適用できません。マッチ/計算を事前に作成できず、インデックスを持つ別のテーブルを作成できません。

  $sql1 = "(SELECT * FROM ci_sanctions_properties WHERE prop_type='LASTNAME' AND prop_value!='' AND MATCH(prop_value) AGAINST ('+usama bin laden' IN BOOLEAN MODE)) UNION (SELECT s.* FROM (SELECT levenshtein(prop_value, 'usama bin laden') AS dist, sanction_id, prop_type, prop_value FROM ci_sanctions_properties WHERE prop_type='LASTNAME' AND prop_value!='') s WHERE dist < 3) ORDER BY sanction_id"; 

     $sql2 = "SELECT * FROM ci_sanctions_properties WHERE prop_type='LASTNAME' AND prop_value!='' AND MATCH(prop_value) AGAINST ('+usama bin laden' IN BOOLEAN MODE) ORDER BY sanction_id"; 

     $sql3 = "SELECT s.* FROM (SELECT levenshtein(prop_value, 'usama bin laden') AS dist, sanction_id, prop_type, prop_value FROM ci_sanctions_properties WHERE prop_type='LASTNAME' AND prop_value!='') s WHERE dist < 3"; 

答えて

4

MySQLだけに縛られている場合、簡単な解決策はありません。

通常、これは、候補候補ルックアップ・フィルタリングのための特別なngram索引付けを使用して解決され、すべてのペアに対してlevenstheinを計算するよりも速い10-50候補の場合にのみlevenstheinを計算します。

のSolr/Luceneのような特殊な全文検索エンジンは、この中に内蔵されている。

PostgreSQLは同じように動作しpg_trgmのcontribモジュール(http://www.postgresql.org/docs/9.0/static/pgtrgm.html)を持っています魅力。

全文索引を使用してこれをシミュレートすることもできますが、すべての文書から単語を収集してngramに変換し、全文索引を作成し、すべてをハックして高速検索しなければなりません。冗長性、同期性などあらゆる種類の問題を引き起こします...あなたの時間の価値はありません。