形態素解析

MySQLで全文検索

MySQLで全文検索やりたくて色々調べてました。ちなみに今までは独自にプログラム側で形態素解析した結果をシンプルな転置インデックスに格納する方法をとっていました。シンプルな方法なので、転置インデックスのキーと（大文字小文字、全角半角の違い程度は吸収してますが）完全に一致しないと検索できないという不便なものです。なんでこんなことやってるかというと、fulltext（GIN）インデクスが無い時代のPostgreSQLを使ってたときのコードを流用したからですｗ

たぶん一番メジャーなやり方はfulltextインデックスを付ける方法でしょう。fulltextインデクスは半角スペースなどを文字の区切りと認識（西洋の言語に特化）するため、そのままでは日本語に使えず、データを格納するときに形態素解析またはn-gramで分割した語を半角スペースで区切って格納する、という処理をアプリケーション側に実装する必要があります。これでも今までの独自実装よりは実装が楽なので全然OKなのですが、追加・更新・削除のパフォーマンスが気になります。

もう一つは、Sennaという全文検索エンジンをMySQLに組み込んで使う方法です。最近はTritonnプロジェクトというところでSenna組み込み済みのMySQLのバイナリを配布してるので、導入の敷居は低いです。モバゲータウンやニコニコ動画もこれを使ってるという噂を聞いたことがあるので、パフォーマンスも問題ないというか現実的には最速に近い方法なんだろうと思われます。唯一の問題は今稼働中のMySQLから切り替えなきゃいけないということです。もちろん通常MySQLとTritonn版MySQLを共存させることもやれば出来ると思いますが、下手して環境が壊れるのも嫌なので、AmazonEC2でもう一台サーバを調達してちょっとテストしてみたいなと。

風が吹けばアフィリが儲かる

2/2に4万5千PV/日を達成した例のサイトの話ですが、現在27万PV/日となってます。でも全然アフィリが儲からない。AmazonEC2の利用料を差し引いたらいくらも残りませんT-T

まぁ、PVは6倍程度になったけど、UUが2倍弱にしかなってないからねぇ・・・

平均PV15てどんだけｗ

とまぁ、全然儲かってないと言いながらもここ約1ヶ月で少し傾向のようなものが見えてきたのでメモ。

午前5時～6時が一番1時間あたりのPVが少ないのですが、アフィリ経由の購入は一番多い。

休日に天気が悪いと昼間でもアフィリ経由の購入がある。

今日は強風で電車の運行に支障が出てるからか分かりませんが、お昼の最高購入数を更新しました。

風が吹く→電車が止まる→休日にお出かけできない人が増える→家でインターネットする人が増える→サイトの来訪者が増える→アフィリが儲かる

なんか風が吹けば桶屋が儲かるみたいで自分で考えててウケましたｗ
まぁでもそういうのはすでにコンビニなどでデータ化されて利用されてるらしいのであまりバカにできない話なのかも。

男の料理

昨日彼女が「明日の夕飯作って食べさせて」と言ってきて「分かった」と答えてしまったので、今日は夕飯を作ってみることに。

いつもは彼女が作ってくれるので、僕は殆ど料理しません。僕が出来るのはパスタをレンジでチンして市販のソースをかけて食うぐらい。あとポップコーンを種から作ることぐらい。それは料理じゃないですね。

彼女は本業の他に料理教室やるような人なので、何を作ったらいいか真剣に考えないといけません。

そういえば去年のクリスマスに、 ローストビーフに挑戦して、失敗して、凹んで、慰められるという醜態をさらしてしまったので、ちょっと今回は頑張ってみようかな。

しかし料理は苦手です。男は黙ってにぎりめしとか言ったら怒られるかな。

後回しと言っていたWebセルオートマトンですが、ブログ集約サイトのページ構成が頭に浮かばないままだったので、とりあえず手をつけてみました。

で、とりあえずセルオートマトンの核となる世代交代の処理を完成させ動かしてみました。

形態素解析にはYahoo! APIを使ってて、ある程度予想はしていましたが、出現する単語が、”by”とか”at”とかHTMLの実体参照の記述の一部と見られる文字など、単体では意味のない単語が頻出しました。

でまぁ、そういう単体では意味のない単語を除外するため、ちまちまと禁止単語リストを作成して、それなりに意味のある単語が残るようにはなりましたが、何度か世代交代させてるうちに処理スピードの遅さが目立ってきました。

検索結果の取得も、ページの内容の取得も、形態素解析の結果の取得も、インターネット経由であり、処理スピードの遅さもその部分が原因だということは深く考えるまでもなく分かりました。

で、とりあえず形態素解析をYahoo! APIからmecabに切り替え、 検索結果の取得とページの内容の取得の部分をローカルにキャッシュするようにしました。(今回のセルオートマトンでは1回の世代交代で同じキーワードで複数回検索処理が動く可能性が高いため)

で、ある程度早くなったものの、それでも8世代目以降になるとアホのように時間が掛かります。20分とか。

それでどこがボトルネックなのかを調べるため、世代数と処理時間の関係を調べてみると、7世代までは生きてるセル数と処理時間がほぼ比例してるのですが、8世代以降に処理時間が跳ね上がっています。

さらに、8世代以降は、HTTP_Clientがタイムアウトのエラーを出すようになっていたので、外部ページの取得で時間が掛かっているのは明白です。

とまぁ、今回はここまでです。HTTP_ClientからHTTP_Requestに切り替えて、タイムアウト10秒とかで処理するようにしてみたいと思います。

Yahoo! APIを使う場合の大まかな流れは、「APIへリクエストを送るためのURLの組み立て→そのURLでデータを取得→XML解析して必要な情報を取得」ってところだと思いますが、個人的には最後の2つ「そのURLでデータを取得→XML解析して必要な情報を取得」については、simplexml_load_fileを利用するのが簡単です。

URLの組み立てについては、オフィシャルを見ると十分でしょう。

そんなこんなで、Yahoo!APIを使い形態素解析をしてくれるクラスを作成し、さらに、そのクラスを利用し、あるURLの文章の中で一番出現頻度の高い単語を取得する関数を作成しました。SimpleXMLクラスの扱いにちょっと戸惑いましたが、Yahooの形態素解析の場合は、簡単に次の方法で一番出現頻度の高い単語を取得できます。

$xml = simplexml_load_file(Yahooの形態素解析へのリクエストのためのURL);
$keyword = $xml->uniq_result->word_list[0]->word[0]->surface;

これで$keywordに一番出現頻度の高い単語が取得できます。
実際は、エラー処理などでもっと複雑になってます。

とりあえず、URLを渡すと文章を取得しその文章をYahooの形態素解析にかけて、一番出現頻度の高い単語を取得する関数が完成しました。
次は、単語を渡すとYahoo検索結果の1件目のURLを返す関数を作成したいと思います。