rottelって

ブログ | 2008/2/28 16:29
投稿APIがないのか。
タグ
kuwa
ないです。
APIで投稿なんてさせません。

いや、強い要望があれば考えますけれど。
というか、実装してくれてもいいですけれど。
kuwa | 2008/02/28 16:49
imbe
APIなんていらないですよ、きっと。
imbe | 2008/02/28 17:14
kuwa
なんか、常に馬鹿にされてる感じ。
フンッ。

そうだ、
MySQLでうまい検索の構築方法を教えて下さい。ポストマップで検索の負荷が大きくて、足引っぱっちゃってるのです。
kuwa | 2008/02/28 19:59
Sennaとかいれてるんですか?
imbe | 2008/02/28 22:32
kuwa
お、senna。素敵なキーワードありがとう。
とかって、他に何があるの?

調べるから教えて。
kuwa | 2008/02/28 23:21
kuwa
もう一つヒントちょうだい。
SELECT count(*) cnt FROM table1 t1, table2 t2 where t1.id=t2.id;

どうもこれだけで1.3秒ぐらいかかるのです。
なんかないでしょーか。

table1は、176375レコード
table2は、97091レコード
なのだけれど。
kuwa | 2008/02/28 23:32
mysql組み込みじゃないですけどHyper Estraierとかですかね。

sqlのほうはそれぞれidはprimary keyですか?
imbe | 2008/02/29 01:07
kuwa
いいね、相談室。

片方だけプライマリー。両方プライマリーにしてみたけど、あまり変わらなかった。なんか今は、0.4秒ぐらいになってる。他の負荷の問題だったのかも。

でも、もう一個条件を足すと、
SELECT count(*) cnt FROM table1 t1, table2 t2 where t1.id=t2.id AND t1.type = 'imbe';
1.7秒掛かる。

・・・・
MySQL組込みがよさそうだから、セナでプロストしてみます。
kuwa | 2008/02/29 02:54
imbe
t1.typeはINDEX貼ってます?
imbe | 2008/02/29 10:54
dera
カウントが更新されるときに、カウントしてカラムに入れるようにして
取得するときはそのカラムを見るようにするってのはどうでしょう。
登録時にちょっと負荷かかりますけどね。

リアルタイム性が必要ないならバッチで更新でもいいかも。
dera | 2008/02/29 12:14
kuwa
うん、そのあたりは考えて、実装してる部分もあるんだけど、検索とかが入ると総数が変わるから、そこは動的に取得したいケースなのです。

あー、いや、圧倒的に見られるのは、検索しない初期ページだから、そのページだけでもそうすれば劇的に変わりますね。
クエリーキャッシュみたいな設定をもっと大きくしとけばいいのかな。

t1.typeはindexついてます。
kuwa | 2008/02/29 14:19
imbe
メモリある程度載ってるならmy.cnfをhuge用のを参考に書き換えてみるとか。
テーブルの構成がわからないのでなんとも言えないのですがjoinの方法を変えると早くなったりならなかったり。
imbe | 2008/02/29 17:30
kuwa
けっこう、hugeかそれ以上にしちゃってるんですよ。

今日は、sennaをインストールしようとして一日が終わってしまいました。
結局インストールできてないので、当分忘れたい。
configureとかmakeとか、MacPortsとか、そんなの僕には敷居高すぎなんだよな。

今は、REGEXPで、全文検索してるんだけど、Sennaだと圧倒的に変わりそうだから、なんとかしたいな。

もうちょっと調べて止めよう。
kuwa | 編集回数: 2 | 2008/02/29 21:20
kuwa
Sennaのmecabインデックスで思ったんだけど、
例えば、青森県が青森と県でインデックス化されると、青森県の検索で引っかからなくなるのかな。

挫折したので、当分考えるのやめる。

で、質問。
MySQLのカラム型で、TEXTと、LONGTEXTって、どのあたりが違うんでしょう。Sennaの
WHERE MATCH(body) AGAINST('投票')
の構文はLONGTEXTだとエラーになる。
あまり使うべきじゃないのかもしれないな。
kuwa | 2008/03/01 21:23
imbe
どうなんですかねぇ。
グーグルの検索みたいに検索キーのほうも形態素解析されてるんじゃないんですかね。

TEXTは、最大65535バイト
LONGTEXTは、最大4294967295バイト
って話じゃなくてですかね?

あれ、結局インストールできたんですか?
imbe | 2008/03/03 11:01
kuwa
いや、インストールは挫折しました。
で、昨日からサーバーが固まりがち・・・。
昨日はhttpdのプロセスが多くなり過ぎだと思っていたんだけど、今日はmysqlっぽい。何か見直さなきゃだめだ。

65000バイトってことは、3万字も入るのね。
LONGTEXTカラムをTEXTに直していってみる。
kuwa | 2008/03/03 12:28
longtext で可能か、sennaで試してみました。
正常に動作しているようなので、senna的には問題ないと思います。
ただ、longtextだとサイズが大きいので、領域を使ったりで
遅くなる要因になります。

REGEXPよりもLikeの方がおそらく早いです。
精度はちょいと下がるかもしれませんが・・・・
instrももうちょい早いかも。

select * from test where body like '%所沢市%';
select * from test where instr(body,'所沢市')>0;

参考になれば、幸いです。
cerezo | 2008/03/03 15:01
kuwa
すっごい、参考になりやす。instrなんてしらなかったですよ。
どれが速いか、テストしてみます。
kuwa | 2008/03/03 15:35
imbe
instr!?
自分も知らなかったです。
さすが!

REGEXP使ってるのってなんか理由あるんじゃないんですか?>kuwaさん
imbe | 2008/03/03 17:09
kuwa
いま、ちょうど便所で思い出しました。

LIKEだと検索漏れがでるんだった。
http://karasu.net/blog/537

あの頃と、MySQLのバージョンとか変えてる筈だから、それも含めて検証してみよう。
kuwa | 編集回数: 1 | 2008/03/03 17:21
dera
さすが!mysqlマスタだね。
dera | 2008/03/03 17:37
kuwa
ちょっとテストしてみた。
168974件のレコード
longtextのフィールドを検索

SELECT SQL_NO_CACHE * FROM t WHERE f REGEXP '大学';
SELECT SQL_NO_CACHE * FROM t WHERE f LIKE '%大学%';
SELECT SQL_NO_CACHE * FROM t WHERE instr(f,'大学')>0;

こんな感じで。何回かやってみたけど、REGEXPがわりと強い。

REGEXP > LIKE > INSTR
regexp -> 表示中の列 0 - 29 (623 合計, クエリの実行時間 0.0128 秒)
like -> 表示中の列 0 - 29 (623 合計, クエリの実行時間 0.0144 秒)
instr -> 表示中の列 0 - 29 (623 合計, クエリの実行時間 0.0260 秒)

ソートを入れると、likeとregexpが同じぐらいになるのだけれど、何かが影響するのかな。わかりません。

longtextをtextに変更しても、そこは変わらない様子。
前は、LIKEで「大学」で検索漏れがでてたけど、それはなくなった様子。
kuwa | 2008/03/03 18:42
お役に立てず、申し訳ないです。
細かいところだと、
count(*) よりも count(カラム名) の方が早いと思います。
count(t1.id) 見たいな感じで。

下記の場合、t1.id と t1.typeの複合INDEXと、t2.idのindexを作成すると
早くなるような気がします。
SELECT count(*) cnt FROM table1 t1, table2 t2 where t1.id=t2.id AND t1.type = 'imbe';

既にやっておられるかもしれませんが、
explainを使用して、インデックスの状況等を確認してみるとよいかもです。
cerezo | 2008/03/04 03:02
imbe
とりあえず頑張ってSennaを入れてくださいよ。
しかし16万件もデータあるなんてすごいですねぇ
imbe | 2008/03/04 10:55
kuwa
だから、Sennaは挫折したんですよー。

暇になったら、うちに来て入れてください。
だいたい僕は、MySQLをパッケージからしかインストールしたことがないんですよ・・・。
そうだ、OSX用のSenna入りパッケージ作ってください。そしたら、みんなの役に立ちます。

・・・
なんか、検索テストしてみて、遅いのは検索じゃなくてソートとトータルレコード数だなとうことに気がついたので、複合インデックス研究してみます。

前に少し調べたときは、いろんなバリエーションでソートしたい場合、よくわからないなということで、ほったらかしていました。
kuwa | 編集回数: 1 | 2008/03/04 12:32
imbe
Sennaは考えてみるから新しいMac買ってください。

ソートとカウントはjoinしてるせいじゃないかと思うんですが。
なんともいえない。
imbe | 2008/03/04 14:13
kuwa
ジョインってLEFT JOIN? そうかもしれない。

ちょっと、HyperEstraierを調べてみた。
どうやってMySQLと連動させればいいかわからないけど。

新しいMacって薄いやつ?
kuwa | 2008/03/04 14:44
imbe
HyperEstraierはcerezoさんにまかせる。
Macは薄くないほうのやつです。

目指せ30コメンツ
imbe | 2008/03/04 14:56
kuwa
16万件ぐらいって、まだまだMySQLだけでもいけるレベルのように思う。
住所DBで350万件ぐらいのデータあるけど、検索はぼちぼちのスピードでできる。
問題はソートだ、ORDER BYだ。

ええと、サポートしてくれるなら、Mac mini一台提供することぐらいは検討するよ。ついでにそのminiをサーバーにして30サイトつくってくれてもいいよ。

macbook持ってなかったっけ?
kuwa | 2008/03/04 15:51
imbe
mysql自体は1000万件とかはいけたような気がします。
ただ単純に個人のサイトで16万件ってすごいなぁと思っただけで。

はるか昔のibookならもってるんですが最近すこぶる調子悪い。
macminiじゃディスプレイ買わないといけなくなるしそれは邪魔なのでお断りします。
imbe | 2008/03/04 20:29
kuwa
それはさ、優しくサポートを断ってるんだよね。
はらへった。豚鍋研究所に行きたい。
kuwa | 2008/03/04 21:09
imbe
30コメンツ超えたので次の記事に移ります。
imbe | 2008/03/04 21:30
縮小 拡大

ログインしておくと、後で編集が可能です。

Rottel内コンテンツ

ユーザー一覧

Rottelとは?
利用規約
開発飲料
利用者の声
ヘルプ
close