2005年06月30日

アプリ★ゲットがやらかした件について

ご丁寧に2発も。
ギガアプリがやらかした時とは送付先のジャンルが異なってる感じですな。
まぁ情報の対象が違うのですけども。

対岸の火事じゃなくって、自分を身をしきしめないとね(←何故か変換でき名)

Posted by Yappo at 15:33 | Comments (0) | TrackBack

こがいだんさん


AA化キボンヌ

7/1追記
AAきたーーーーーー11!!1


  /⌒ ⌒ヽ、
 // ノノノヽヽ
〃σ--(ヘ)-(ノ)
 || ;ミ  ω 彡  <
 ヽ;ミミミ∇彡   
    ゙゙゙゙゙"" 

Via 読書記録ChangeLog

Posted by Yappo at 14:16 | Comments (3) | TrackBack

Rast0.2.0きたーーー!

ライセンスをGPLからBSD ライクなライセンスへ変更したのが大きな目玉っぽい
新興検索エンジンはどれもGPLに縛られなくなりつつありますな。Hyper Estraierは元から違うけど。
ビッグな追加事項は0.2.1?あたりっぽい

とりあえずRast.pmの更新は待ってくださいorz
マージとかXML-RPCとかそれは心得てますorz

先にSennaのMySQLパッチの有用なパッチつくりを先に。。。


と、ソースコードも追わずに脊髄ポスト

Posted by Yappo at 01:36 | Comments (2) | TrackBack

2005年06月29日

iYappoのフロントPerl化完了

いつの間にかPHPからPerlにスイッチしました。
使い慣れたフレームワーク上で再構築したので、保守性はかなり上がった感じです。
Perlだから保守性が上がったわけでは無いけど。

基本的にYappoLabsのコードからのバックポートという形でiYappoV9です。
YappoLabsの完成系がiYappoXなので。

Xで予定していた要素をがりがり突っ込んでいく感じです。
既に登録サイトの重要そうなURLのコンテンツ全てを全文を検索対象にしていたりします。

もろもろの条件が整ったので、近いうちにサイトオーナー向けのサービスもリリース出来そう。

いわゆる元唯一なハイブリッドなサーチエンジンとしてやれる事が大幅に増えた感じ。
次期WebRobotの本稼動も近いかも。
ぶろぐうおっちゃぁあのようなめたにんしきかとかぎいあいえすあたりのけいさんとか

ちなみに「ある程度のボリュームの件数が引っかかると云々」の件は、お蔭様で解消されました。
今の悩み事は、A9 opensearchに対応する意味が有るのか?キーワード検索結果のRSSうわなにをするあいえふぁfべyぎpれb

Posted by Yappo at 04:33 | Comments (0) | TrackBack

MySQLとSenna+MySQLのメモ

ただのメモ

SQL_CALC_FOUND_ROWSを使うと、結局最後までMYDを見ちゃうからパフォーマンスが落ちる
match文を使いつつfieldに通常のwhereすると結局limitの数だけwhereの条件に一致するレコードを読んで遅くなる。要するにmatch文だけなら、それだけで読むべき行が求まるのにMySQLの通常の演算が入るとまんどい。
alter table order byして、あらかじめソートしたテーブルも、MySQLのindexをキーにして検索するとselect order byしないと結果にならない。でもSenna+MySQLのfulltextインデックスのみでwhereしたら意図したとおりになる。
少なくともSenna Rev21のバインディングではこんな感じ

Posted by Yappo at 03:56 | Comments (0) | TrackBack

2005年06月23日

メモのスナップショット

最近は随分とパフォーマンスが上がったiYappoな訳ですが
ちょろちょろとDBのチューンは続いてます。
ある程度のボリュームの件数が引っかかると急にパフォーマンスが下がり出してて悩んでます。
SennaとMySQLどっちでボトルネック出てるのか調べる作業をやれてない感じで。
ただのselectてsort処理など余計な事はしてないので、data fetch処理のどこかでボトルネックある予感。
それか、Senna→MySQLのdoc id受け渡しのループかな。
一度全部MySQLに渡さなきゃいけないからなぁ…
memcpyして一瞬で終わらせられないかな。。。
あとは、Sennaの最近のリビジョンはindexのフォーマットが変わったそうで、悩みの種が増えたりしちゃったり。(運用的な悩みで他意はないっす)


調子に乗って、検索対象の文書データを大幅に増やしたりしてます。
とかやってるうちにgooが1500万文書からの検索とか発表されとりますが
iYappoの方は数十万件から徐々に増やしてこうって感じですな。
まぁ、検索結果数は変わらずに増える感じで。


他にも調子に乗って、画像・着うた・動画・着メロの検索をiYappoの内部に取り込んでたりします。
綾瀬メソッドも簡単に見つかります。


なんだかんだで、gooともgoogleともベクトルが被らない様で気が緩んだ75の初夏。

Posted by Yappo at 22:43 | Comments (1) | TrackBack

2005年06月19日

NAMAAN


ゲッツだぜ

Posted by Yappo at 20:17 | Comments (0) | TrackBack

2005年06月18日

綾瀬メソッド

高橋、もんた、miyagawaに続く新しいメソッドが登場

綾瀬

メソッド


もんたメソッドネタにトラックバックしてくださったSensitiveさん経由で発見した

まずは、綾瀬メソッドのプレゼンをご覧頂こう。

( ゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡 _ (゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ (゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡 _ ( ゚∀゚) ⊂彡 _ ∩ ( ゚∀゚)彡

deliciousったのは秘密

Posted by Yappo at 02:44 | Comments (1) | TrackBack

2005年06月17日

iYappoのコアをSennaに置き換え

YappoLabsはRastですが、本番環境にSennaという検索エンジンの種を使いました。

負荷的な問題が顕著になって考えた末、本運用系のiYappoのキーワード検索MySQL+Sennaを使うことにしました。
当然のことながらSennaはN-gramを使うように書き換えてます。
理由はLCの時に話したとおり、携帯系は特に分かち書きに適さないから。
また、my.cnfで認識可能な最小キーワードサイズを2バイトに変更。
ギャル語でもなんでもおkっす。

基本的にiYappoの検索対象データは、一日に数回全部作り直す仕様なので
DBサーバの障害時でのSenna特有のリスクは最小限になっているかと思われます。

検索速度とマシン負荷が劇的に向上しました。
さすがlike '%key%'な検索とは違う。

検索速度に余裕が出たので、iYappoを本格的な全文検索エンジンに仕様変更しました。
登録サイトのトップページを含む数件のページの文章をiYappoの検索対象に含めています。
Yahoo!mobileともgoogle mobileとも区別できない独自路線です。
他にも新ネタ仕込み中ですよん。

indexスピードは
旧世代のサーバ上で
平均1.5kbの11万件強のテーブルのindex速度が約12分。
デフォルトのmecab利用時はもっと早くなるでしょう。

あと、mysqldでの最短検索キーワードを2バイトに設定した影響で
Sennaは全角一文字だけの検索キーワードは完全にヒットしない仕様を発見した。
2-gramだから、文字境界の端でしか引っかからないという感じですかな。
まぁ、完全にしようとするとコストかかるからなぁ。

ついでにindexの張り方やらqueryの投げ方やらcrontabの微調整を行って
積み重ねでパフォーマンスあっぷん


とにかく、道具を有効活用するのは使う側の判断しだいですよと。
最適な道具を選びましょうね。

Posted by Yappo at 04:10 | Comments (0) | TrackBack

2005年06月16日

複合語検索ワードの行列演算

パテント対策の走り書き

複合語検索されやすい単語は重要度が高くて
その重要度が高い単語と一緒に検索された単語も重要度が高い

で、それらの関係を表にして行列演算!

なーんか面白いよね?

#ceekの中の人のネタを組み合わせた形で、iYappo上で実物をお披露目しよっと

Posted by Yappo at 22:30 | Comments (0) | TrackBack

2005年06月12日

グロ注意。刺身食べたいからマグロ解体した






もう疲れて食欲なす

Posted by Yappo at 22:15 | Comments (1) | TrackBack

2005年06月09日

MFPMにてもんたメソッド対応しました

別にこれをしたいから作ったわけじゃないのだけど、せっかく作ったから使わないとって事で導入です。
利用例はAcme::Montaの詳細にて。

まぁ、ASPやらCMSのモジュールとしてもんたメソッドを実装する時には強力だと思うのですよ。
はい。

どんなアプリにももんたメソッド!Viva!

Posted by Yappo at 10:51 | Comments (0) | TrackBack

Acme::Monta - (ry

さらに悪ノリしますた。


use Acme::Monta;
my $monta = Acme::Monta->new();
print $monta->montaize('健康になるには<monta>野菜</monta>の摂取が大事');

こんな感じです。

<monta>タグでくくられた内容をmontaizeします。
ようはもんたメソッドもじゅーるですな。

マウスカーソルの変更メソッド名のネタを頂きました。


Acme::MontaでCPAN登録済みというオチですが。

なのでperl -MCPANでどうぞ。

Posted by Yappo at 01:35 | Comments (1) | TrackBack

2005年06月08日

del.icio.usとはてなブックマークの同期を取るモジュール

ついにはてなのIDを取得したわけで、存在をしってからやは5年目での加入でしょうか。
del.icio.usとはてなブックマークのどちらかを使うって選択するのももったいない話なので
同期とって便利に使えないかな?という事で、同期を取るためのモジュールを作ってみました。

WebService::SyncSBS::D2H

使い方は、./examples/sbssync.plを見ていただければ分かるかと。

tags、url、サイト名、コメントを同期させることが出来ます。
はてなブックマークにXML::Atomをつかってポストしようと思ったんですが
postするXML中に実態参照があると、はてな側で&をさらにescapeしてしまい

<xmltag>&0ueeee;</xmltag>

という内容で送信すると
&amp;0ueeee;

と表示されて泣きそうになりました。
なので、はてなにpostするXMLを独自で生成してpostしてます。

ここからが重要です。
はてなブックマークのAtom Feedにはtagsの情報が省かれているため、はてな->deliciousの同期処理を実装してません。
tagsの処理を後回しに書いてたので気づきませんでした。。。
むしろ脱力して公開する気なくして1週間放置してました。
はてなアイディアに要望出さなきゃな。。。
要望だしたー!

Posted by Yappo at 10:32 | Comments (0) | TrackBack

2005年06月06日

手づくりサラダ食いたいから畑つくった



庭先を大改造
土作りは去年から
トマト、キャベツ、枝豆、トウモコロシ、ハバネロ、スイカ

IT屋さんも畑仕事出来なきゃいかんと思うのですよ

Posted by Yappo at 12:39 | Comments (0) | TrackBack

2005年06月03日

Linux Conference 2005 発表資料

お話してきました。
今日の敵は尿意でした。
いやな汗ずっとかいてました。
我慢してたら最後の方は収まってきました。

あと、パワポのリハーサル時のページ切り替えタイミングを保存していたらしく。
パワポとも戦いました。
二面楚歌です。

ということで、発表資料です。
Yappoの思想すべて見せます
題名の突っ込みは、本人からのみ受け付けます(え?)
iYappo/YappoLabsでの実例やアーキテクチャ紹介を交えながら、選定基準や今後の事について話しました。
正直いうと要求に見合った選定をきちんとする事が大事です。
終わった後に、とある知人が経営している会社の中の人から、オススメを聞かれたですが機会があれば後日お話できればいいな。という感じです。

ところどころ、笑われるようなネタを入れつつって感じです。
途中、サーチストリームのデモを行いました。

スタート
スタービーチ(6) アルバイト(24) 任天堂(51) 淫らな告白(7) 着うた フル(151) 恋 画(2383) 翻訳(102) (?) 任天堂(51) 改造コード(14) 画像(1741) ??????(?) 怖い(64) 個人輸入(68)
--------------------------------------------------------------------------------
終了。

狙いどおり、変な言葉が出たです。

後半は、あんな検索会社検索会社検索会社なんていう凄いところへ言ってきて、お話した内容をサマリーにした感じです。
検索会議でスルーされたネタの真意でもあります。


というわけで、お呼びいただいきありがとうございます。

突っ込み、個別質問なんでもござれ。

Posted by Yappo at 16:40 | Comments (2) | TrackBack

いよいよ始まり


でう

Posted by Yappo at 10:03 | Comments (0) | TrackBack

2005年06月02日

Rast,Hyper Estraierの性能評価クリップ

Ceekz Logsさんと/.jのOliverさんが、性能評価をしているのでクリップするテスト。

Ceekz Logs Hyper Estraier のお試し結果

前回、調子乗って行っていた100万件のニュース記事のインデキシングですが、9時間ほど掛かりました。これは、月別に差分インデキシングを行ったからかもしれません。合計で 1.0G ほどかな。

他にもソートの速度が気になっているそうです。
Hit件数が多くなるとソートに必要な処理も増えてしまうので、ある程度諦めてしまうのか
高性能な仕組みを考えなくちゃですね。。。
それかインデックスを分割して、後ろの順位をばっさり切り捨てるとか。

Oliver の日記 全文検索エンジン:Hyper Estraier

速度低下はかなりリニアで、とても素直な挙動といえる。indexのサイズも元のデータが693MBなので、かなり優秀。成長させていったindexに対してestcmd optimizeを実行したところ、300MBまで縮んだ。

Oliver の日記 全文検索エンジン:Rast (ちょっとチューン)

ディスク上のDBへのsync回数を減らすことで実時間ベースのパフォーマンスは劇的にアップした。この範囲で5-8倍であるというのは、ストレートにsync回数が減ったのが響いていると思われる。この設定での使用メモリは約300MB。しかし、テストで16万エントリをいっきに登録するテストをしたところ、10万エントリを越えたあたりからパフォーマンスは劇的に低下していった。

初のRastとHyper Estraierを(おそらく)同じ文書群での性能を検証をした情報ではないでしょうか。
Rastでは約4時間40分かかっていたindex処理を、Hyper Estraierでは約12分で完了している模様。
早すぎ、、、ですが詳細なindex条件が記載されていないため参考程度ですな。
自分も検証しないと。。。

BDBをチューニングしたり、RastのDBエンジンをQDBMに変えちゃうとパフォーマンスが上がるのかを試してみたいところ。


ちなみに明日のネタは、YappoLabsの採用基準やiYappoのアーキテクチャを絡めつつ
前回のネタの紹介部分を省いた感じになると予想されます。
シナリオは大体あるので、さくっとパワポが作れるといいな。

Posted by Yappo at 16:39 | Comments (0) | TrackBack