0

私は db コンサルタントを雇いました。彼は、私の現在の完全な mysql システムの全文検索側を処理するために solr の使用を推奨しており、しばしば遅い検索を高速化します (検索あたり最大 30 秒)。

彼/私たちの大部分は、a) mysql 設定を微調整して余分なパフォーマンスを絞り出すこと、および b) solr をインストールすることに費やされました。しかし、今は終わりに近づいており、最初のいくつかの solr テスト クエリは失敗しているようです。

まず、現在の完全な Mysql セットアップの関連する 3 つのテーブルと、MySQL/Solr アプローチに置き換えようとしている完全な MySQL クエリを次に示します。次に、テストしている Solr クエリです。

TABLE1 - 全文検索レコードが格納されるメイン テーブル。songID 列、Artist 列、および Title 列で構成されます。INDEXES - songID primary、Artist Fulltext (非一意)、Artist btree (非一意)、Title Fulltext (非一意)、Title btree (非一意)

TABLE2 - DJ ソング リストの保存用。上記のテーブルの ID を参照します。一部の DJ には 150,000 以上の曲があるため、TABLE1 の曲を参照する 150,000 以上の行がここにあります。また、TABLE2 には ID 列と曲バージョン列 (バージョン名) があるため、DJ は同じ曲の複数のバージョンに独自のバージョン参照を適用できます (つまり、同じ曲の複数の行で、それぞれが異なるバージョン データを持ちます)。INDEXES - ID プライマリ、djID btree (一意でない)、songID btree (一意でない)。

TABLE3 - TABLE2 の ID への参照とタグの ID (TAGS と呼ばれる別のテーブル) を含むタグ マップ テーブル。ジャンル、言語、年代の各曲のタグを TABLE2 に格納します。また、DJ は複数の曲リスト (List1、List2 などのタグ付き) を持つことができるため、各曲が属する曲リストへの参照が含まれます。各曲には、DJ ごとに最大約 12 個のタグを付けることができます。INDEXES - 行 ID プライマリ、ID btree (一意でない)、tag_id (一意でない)

アーティスト キーワード「beatles」の現在の mysql 検索クエリは次のとおりです。関連する唯一のタグは、DJ 33 の List1 の曲に一致するもののみを選択するように指示するものです。

"SELECT t1.*, t2.version 
FROM  table1 t1, table2 t2, tagmap tm, tag t
WHERE MATCH (t1.Artist) AGAINST ('+beatles* ' IN BOOLEAN MODE) 
AND tm.tag_id = t.tag_id
AND (t.name IN ('List1'))
AND t2.ID = tm.ID
AND t2.songID = t1.songID
AND t2.djID = '33'
GROUP BY t2.ID
HAVING COUNT( tm.tag_id )=1
ORDER BY t1.Artist, t1.Title ASC LIMIT {$lastRowNum},{$limit1}";// pagination blah

動作しますが、リストが 5000 を超えると遅くなります。

彼が提案した SOLR ソリューション:

  • TABLE1 の曲の solr インデックスを作成する
  • 検索中に、問題の DJ に属する songID について mysql の TABLE2 をクエリします。

  • Artist のキーワードの solr クエリを作成し、DJ の songID を挿入します...

    .../solr/select/?q=id:(3688804 3688807) AND アーティスト:beatles&wt=json

(ここでは見やすいように、URL とスペースと角かっこを省略しましたが、作業コードでは %20 などに置き換えられています)

上記の 2 つの曲 ID だけの例は機能しているように見えましたが、テストでは、クエリに約 1000 を超える曲 ID を追加し始めるとすぐにクエリが失敗します。一部の DJ には 150,000 以上の曲があるため、150,000 以上の一意の songID を solr クエリに挿入する可能性があることを考えると、これは欠陥のあるソリューションのようです。

また、タグがどのようにクエリプロセスに入るのかわかりません。

ご覧いただきありがとうございます。

4

1 に答える 1

1

Solr を使用することをお勧めしますが、実装は少し異なります。

すべての DB 正規化は、トランザクション システム (つまり、曲の追加、プレイリストの作成など) でうまく機能します。

検索は、正規化されていないデータ構造に対して最適に機能するものです。検索結果を表す Solr スキーマを作成し、SQL クエリを使用して入力するだけです。

クエリは依然として非効率的ですが、すべての検索で (つまり、リアルタイムで) 実行する必要はありません。代わりに、インデックスを毎晩バッチ入力し、曲/プレイリストなどが変更されるたびにデルタの変更を少しずつ行うことができます。

私はこれについてここに何かを書きました。お役に立てれば。

于 2013-10-25T04:41:43.587 に答える