Jan 26, 2006

MapReduce: 大規模クラスタでの簡単なデータ処理 (#318th PTT)

久しぶりにPTTに参加した(#318th PTT (in Japanese))。東大に行くのもチョー久しぶりということもあって根津の坂をのぼるときには感慨めいたものを感じすらした。

今回はGoogleの林芳樹さんがMapReduceの話をしてくれるとあって異様に盛況だった。20人を切ることも稀でないPTTにあって60人以上の参加者。和田英一先生がイニシャルオーダーの話をしてくださった回には及ばないものの、Googleのネームバリューはすごいのね。話の内容はOSDI04のスライドとほぼ同じだったので参加できなかった方は以下を参照のこと。

MapReduce:Simplified Data Processing on Large Clusters

MapReduceフレームワークで気になる点は二つある。

一つはmap操作をiterativeに適用したい場合にはどうするのかということ。もちろん、Reduce関数をid関数にしてMapReduceを繰り返せば済むが非常に効率が悪い。本質的にはMapReduceに加え、単独のMapをフレームワークとして許せばよいと思うのだが。他に副作用のあるMap関数を定義しておいてReduceフェーズをほとんどomitするという方法も考えられるのだが、Mapフェーズが途中で異常終了した場合などにはプログラムが面倒を見る必要が出てくる。もっとも日常的に行うバッチ処理では、あらかじめMap関数を手で合成しておけば実用には堪える。

もう一つはReduceフェーズの負荷分散がrobustでないことだ。システムが処理の多寡を見積もって負荷分散してくれるわけではなく、分散を決定するハッシュを定義(partitioning function)できるだけである。つまりはハッシュ値ごとの負荷が平均的に分散しているという暗黙の前提がある。ハッシュのナイーブさ加減によっては、負荷分散として機能しないというケースも想定される。MapReduceというフレームワーク自体が処理の大半をMapフェーズにfoldingすることを前提にしているのだろうから、仮にReduceの効率が悪くなったとしても構わないと無理矢理納得できないこともないが…。

飲み会はいつもの面々で、いつもの大八。少し酒の入った某さんが割とのっぴきならないことをカミングアウトしてきた。言いたくてしょうがなかっただろうなーと思った(笑)。

Jan 20, 2006

MT 3.2で HTML::Templateのファイルキャッシュを有効にする

Movable Typeでは、mt.cgiなどが生成する画面はHTML::Templateというマクロプロセッサ(≒テンプレートエンジン)を使って実現されています。このマクロプロセッサには大した機能はないのですが、テンプレートを読み込んだ結果をファイルなどにキャッシュしておき、それを再利用することで処理を高速化する機能があります。

実は、MT 3.2以降ではこのファイルキャッシュ機能を簡単にActivateすることができます。方法は、

  1. <MT_DIR>/tmplディレクトリの下にcacheという名前のディレクトリを作る
  2. cacheディレクトリのパーミッションをmt.cgiなどから書き込めるように設定する

...ただそれだけです。

HTML::Templateのドキュメントによれば、「テンプレートの処理パフォーマンスが50%向上する」とのこと。とは言うものの、テンプレート以外の処理の方が遥かにオーバーヘッドが大きいので、このファイルキャッシュを有効にしても大した改善は望めません。

容易にできることなので気軽に試してみてはいかがでしょうか、という程度のmicro tipsでした。

Jan 19, 2006

全国一斉ライブドア祭りの三日目

全国一斉ライブドア祭りの三日目ですが、みなさまいかがお過ごしでしょうか。

今日の時点で416円で売買単位は1株。もし今買いを出せば比例配分です。配分単位は1株なわけで、売り方からすれば相当の量自分で売っていない限りおそらく1株しか約定しないでしょう。業界最大手のイートレード証券の手数料が最低で472円(?)ですから、手取りは416-472=-56円。とんだ投売りですね…。ホルダーじゃないのでどうでもよいのですが。

数あるお祭り銘柄の中で、お祭り的観点から私が注目しているのは、やはりWIDE星人の星、吉村伸氏のメディアエクスチェンジ。先月半ばにライブドア組に入ったばかりですが、今月に入ってからのぶっ飛ばし具合はとても気持ちがよいものがあります。村井純氏の財布もすごい勢いで膨れたり縮んだりしてるわけです(ライブドアのTOBに応じてしまっている可能性はあるけれど)。

livedoor ファイナンス

株式交換で子会社になったわけでもないし、ライブドアと大して取り引きがあるわけでもないし、ライブドアがもしぽしゃってもポータル事業をそのまま引き継げる子会社は多分ここだけ。平成電電にとってのドリテクのポジションをゲットできる千載一遇のチャンスかもYO。

2006-01-23追記: 念のため買い煽りではないですからね。個人的にはPER 15~20でお待ち申し上げております。

Jan 14, 2006

DBコンバート後に受信済みのトラックバックを参照できない問題への対処

このブログで長らく公開してきたmt-db-convert.cgi、およびMovable Type 3.2に同梱のmt-db2sql.cgiに大きめのバグを発見しました。どちらのツールでもコンバート後にすでに受信済みのトラックバックを参照できないという問題が生じ得ます。

現在下記にて配布している0.20以降のバージョンでは、すでに対策済みです。

Ogawa::Buzz: mt-db-convert.cgi: MTデータベースの相互変換 CGIスクリプト

過去に一度でもmt-db-convert.cgiかmt-db2sql.cgiを使ってデータベースを変換したことがある場合には、(顕在化していなくても)潜在的には問題がある可能性があります。不安を煽っても仕方がないので、問題の有無を検査したり、データベースを訂正するためのプログラムも用意しましたので、症状に心当たりがある人は試してみるとよいでしょう。

問題の詳細

mt-db2sql.cgiもmt-db-convert.cgiも、新規のデータベースを作成して元のデータベースからMT::Object単位でコピーしていきます(MTではブログを表現する大抵のデータ構造がMT::Objectのサブクラスとして表現されています)。コピーはサブクラス(オブジェクトの種類)ごとにまずAuthorクラスのオブジェクトを順にコピーし、次にBlogクラスを、さらにCategory, Comment, Entry (中略) Trackback, TBPing (後略)をそれぞれコピーしていきます。

ところが、MT::ObjectのうちEntryとCategoryの保存時には、対象のオブジェクトがトラックバック可能な場合、データベースにTrackbackオブジェクトがあるかどうか問い合わせ、なければ新規に生成して保存するようになっています。

これはトラックバック可能な新規エントリーを作成したりする場合には正常に機能します。一方、コンバート時にTrackbackクラスより先にEntryクラスをコピーすることを考えると多少事情が異なります。新規データベースにはTrackbackオブジェクトは存在しませんから、まずEntryコピー時にTrackbackオブジェクトを一通り新規生成した後、さらにTrackbackコピー時にそれが上書きされることになります。この結果、あるEntryオブジェクトに対応するTrackbackオブジェクトが複数存在する状態が作られます。

例えば、Entryが3個あり、それぞれに関連付けられたTrackbackオブジェクトのidが1,3,5であるという状態を仮定します。Entryのコピー時にはidが1,2,3のTrackbackオブジェクトが新規生成され、Trackbackのコピー時にはidが1,3,5のTrackbackオブジェクトが作成されます。したがって、新しいデータベースには1,2,3,5という4つのTrackbackオブジェクトが作られることになります。

さて、Movable TypeのTrackbackクラスは、エントリーやカテゴリーのトラックバックインタフェースの抽象ですが、EntryオブジェクトとTBPingオブジェクト(受信した個々のトラックバックデータ)を関連付ける役割もあります。さらに悪いことには、関連付ける際にMovable TypeはIDの一番小さいTrackbackオブジェクトしか参照しません。したがって、参照されなかったTrackbackオブジェクトに関連付けられたTBPingオブジェクトも参照されません。この結果として、過去に受信したTBPingとEntryとを関連付けられなくなります。

この問題を避けるには、コピー時に必ずTrackbackクラスを先にコピーするか、Entryに対応付けられたTrackbackオブジェクトが複数あっても正常に動作するように本体プログラムを修正する必要があります。

冒頭でも述べたように、mt-db-convert.cgiの0.20以降では前者の対処を行ってあります。mt-db2sql.cgiへの対処はOgawa::Buzz: MT 3.2日本語版 Unofficial Patchに追加しました。

検査・修正用プログラム

簡単なデータベースの検査・修正用のプログラムを用意しました。

mt-tbfixer.cgi

上記のCGIスクリプトをmt.cgiなどと同じディレクトリにアップロードし、実行権限を与えて、ブラウザなどから起動してください。

何もオプションを与えなければデータベースの検査をしてくれます。

MT::Trackback(id=194) conflicts with (id=198) for entry 928
   MT::TBPing(id=998) can be moved from MT::Trackback(id=194) to (id=198)
   MT::Trackback(id=194) can be removed
MT::Trackback(id=118) conflicts with (id=129) for entry 859
   MT::Trackback(id=118) can be removed
...
 
15 conflicts are found in MT::Trackback!
5 conflicts are found in MT::TBPing!

この例では、mt-db-convert.cgiやmt-db2sql.cgiの実行時に誤って作られたTrackbackオブジェクトが15個あり、それらのトラックバックインタフェースに送信された5件のTBPingオブジェクトがあることが分かります。前者の値が0ならばまったく問題はありません。

次にデータベースの訂正を行うには、まずデータベースのバックアップを取ってください

バックアップしましたね?

いいんですね?

…では続けます。今度は「http://.../mt-tbfixer.cgi?__mode=fix」のように「?__mode=fix」というオプションを付けて起動します。

MT::Trackback(id=194) conflicts with (id=198) for entry 928
   MT::TBPing(id=998) is moved from MT::Trackback(id=194) to (id=198)
   MT::Trackback(id=194) is removed
MT::Trackback(id=118) conflicts with (id=129) for entry 859
   MT::Trackback(id=118) is removed
...
 
15 conflicts are found and fixed in MT::Trackback!
5 conflicts are found and fixed in MT::TBPing!
 
You should perform rebuilding for all MT contents.

と表示された時点で修正作業は終了しています。最後にすべてのページを再構築すれば、コンバートの際に見えなくなっていたトラックバックが表示されていることでしょう。

注: このスクリプトはテストが相当不足しています。チャレンジャーをお待ちしています。
注: このスクリプトはカテゴリーのトラックバックインタフェースを考慮していません。今のところ重要度が低いと考えて先送りしていますが、そのうち実装します。

Jan 11, 2006

AddToHatenaBookmark Plugin

エントリーを公開したときに、そのエントリーをはてなブックマークにポストするプラグインを公開します。Movable Type 3.2以降(日本語版)でしか動作しません。また、はてなのアカウントが必要です。

AddToHatenaBookmark - ogawa - Google Code

このプラグインは、公開状態のエントリーを更新したり、新規に公開状態のエントリーを追加したときに、そのエントリーをはてなブックマークの自分のブックマークに追加するものです(参考: Ogawa::Buzz: Update-n-Ping Plugin)。

イマイチ用途が分かりにくいかもしれませんが、この作業をマニュアルでやっている人もいるようです。自分のブログをはてなブックマークで宣伝できるという一次的なメリットに加え、みんなでこれをやれば、はてなブックマークの検索機能をブログ検索機能として利用できるという二次的なメリットもありそうです(つーか、3ユーザがブックマークしないとダメか?)。

Jan 8, 2006

ブックマークかトラックバックか?

ブックマークかトラックバックか、というムラ社会間闘争には特に興味が湧かない。どうしてもやらなければならないことでもあるまい。

Permalinkの所有者は、閲覧者の都合などということには関心がなく、ブックマークにしろ、トラックバックにしろ、コメントにしろ、リファラにしろ、閲覧者の反応の検出量を最大化でき、検出の遅延時間や手間を最小化できるメッセージング方式であれば(おそらくそれが共通の要求であろう)なんでもよいのである。

この点では、これらの4方式の中でブックマークサービスだけはあらかじめ負けている。なぜなら他の三者はPermalinkに対するダイレクトメッセージングだが、ブックマークサービスだけがそうではないからである。ただし、閲覧者にとってブックマークサービスの実現する、ホットな話題の「検索」機能や、統一的なメッセージングインタフェース(メッセージングインタフェースを持たないPermalinkにもコメントできる)の利便性の存在が依然大きいのは分かる。「ピュア」な技術的観点からは、しかし、Blogosphereのさらなる拡大とブログ検索サービスの長足の発展がブックマークサービスの意義を無効化(ブックマークサービス自体がブログ化するという意味でも)していくだろう、という未来像の方に興味がもてる。

さて、

404 Blog Not Found:はてブってTBできへんの?

さらにbookmarkへのcommentに言及するべく、bookmarkへのTBってのは出来ないのだろうか?

それは、元のPermalinkに対して本来送信されるべきトラックバックが「ブックマーク」というIndirect Permalinkに横取りされてしまうということに他ならない。トラックバックが実現するNotificationの効果がなくなってしまう上に、元のPermalinkの所有者は2段階の参照(*)を行わなければ送信元に到達できないので、あんまり良くないと思われる。

(*) もちろん、IFRAMEを使ったり、はてなブックマークなどが提供しているブックマークページのRSSを利用したりすれば、1段階の参照に縮退させられる。ただし、どのPermalinkに対するブックマークが更新されたのかを検出するのは、人手か場当たり的手法に頼ることになる。これに対して、(通常の)トラックバックではより直接的にメッセージの到着とその内容を知ることができ、だからこそNotificationとして機能する。

ブックマークへのトラックバックを考えるのであれば、トラックバックを受信したら元のPermalinkにもdelegateすることも検討してよいだろう。そうすれば上で述べたような「横取り」効果は解消する。

ついでに普通にブックマークしただけでもトラックバックを送り付けるという仕様にしてしまうということも検討に値する。そうしてしまえば、ブックマークに付記されたコメントをPermalinkの所有者が読み損ねる心配はなくなるし(ブックマークのコメントが減るという心配はある)、トラックバック派だのブックマーク派だのというへんてこなムラ社会間の闘争もなくなる。私は私で「ブックマークサービスだけはあらかじめ負けている」だなんてセンセーショナルな書き方をせずに済み、結果として読者を減らすことができる。まあ冗談みたいな仕様だが。

2006-01-09追記:

もちろん、geekの立場からはどんな機能の実現も否定するものではない。強いて言うなら、「bookmarkへのcommentに言及する」のなら、「bookmarkへのTB」ではなく「bookmarkへのコメントへのTB」の方が相応しい。はてなブックマークというのは、要するに、ユーザごとに「はてなブックマーク」ブログ(そこにはPermalinkとショートコメントを含むことができる)を提供するのに加えて、Permalinkごとに串刺ししたビューやPermalinkごとのランキングビューも提供するサービスなのだから。ただし、現状トラックバックを送信することも受信することもできないなどブログシステムとしての要件を十分には満たしておらず、また「Permalinkごとに串刺ししたビュー」があまりに秀逸なために、多くのユーザにはブログシステムとして認知されていない。

Permalinkごとに串刺ししたビューもまたURLを持つのでそれにトラックバックできること自体は構わないが、その意味するところは「ビュー」自体への通知なのかPermalinkへの通知なのか判然としない。ならばメッセージ自体を複製してやればよいというのが、第一の主旨、つまり「ブックマークブログへの通知」に関する話。

第二の主旨は「ブックマークブログからの通知」を実現せよということ。「普通にブックマークしただけでもトラックバックを送り付ける」という仕様は、「『ブックマークした』というエントリーがトラックバックで通知されるかどうかをユーザが選べない」という仕様を意味するので、abuseだという指摘は当然である。ユーザが選べる方が望ましいのは言うまでもないことで、もしそうなっていれば現状のブックマークサービスのメリットはすべて保全される。

残るのはシンプルで一般的な問題に過ぎない。つまりは、通知のためにトラックバックを送るか、送らないかと、通知のためにトラックバックを受け取るか、受け取らないかだ。言い換えるとBlogosphereにcommitするか、しないかということだ。つまりは(冒頭で述べている通り)ブックマークかトラックバックかというよく見かける論争は、木を見て森を見ずの典型で、不毛にしか思えない。

2006-02-10追記:

はてなブックマークでは、はてなブックマーク - http://blog.as-is.net/ の注目エントリーのように、「ブックマークされたというイベント」に対する通知は受け取れるようだ(RSS形式でも受け取れるようだ)。しかし、コメントの内容が通知されないのでは、やはり不十分だ。

Jan 7, 2006

Flickr2pics: Flickrから livedoor PICSに画像をコピーするスクリプト

livedoor PICSですが、あまり使われていないそうなので(笑)、Flickrの画像をダウンロードしてきてlivedoor PICSにアップロードするスクリプトを作ってみました。50MBとはいえ貴重なネットワークストレージ、有意義に使いましょう。多分ある時点でlivedoor Blog並に(2GBくらいに)一気に増量されるのではないかと勝手に思っています。

http://ogawa.googlecode.com/svn/trunk/flickr2pics/

Flickrの画像情報を取り出すのにFlickr Servicesを、livedoor PICSにアップロードするのにlivedoor PICS WebServiceをそれぞれ使っています。「2.0」ぽいですね。Webでサービスしてもよいのですが、トラフィックが洒落にならんのとBrute force attackをされるとかなわんので止めておきます。

スクリプトを動作させるには以下のPerlモジュールがインストールされている必要があります。

スクリプトの冒頭の変数$FLICKR_USERNAME, $PICS_USERNAME, $PICS_PASSWORDを自分の環境に合わせて修正した後、コマンドラインから起動すれば動作するはずです。

注意事項

このスクリプトはflickr.people.getPublicPhotosを使って$FLICKR_USERNAMEで指定されたユーザのPublic Photoのリストを取得し、それぞれの画像に対してflickr.photos.getInfoで詳細情報を取得しています。したがって以下のような制限・留意点があります。

  • Publicでない画像はコピーできない。
    →我慢してください。
  • $FLICKR_USERNAMEに他人のユーザ名を指定してももちろんコピーできてしまう。
    →絶対にやめましょう、特にこのスクリプトを使ってやるのは。
  • 場合によってはカップ麺が作れるくらい時間がかかる。
    →文句はFlickrにどうぞ。念のため、今のところPICS APIがやたら速いせいで確かにFlickrの遅さが目立ちますが、PICSユーザがそこそこ増えればPICS APIもビジーになってどうせ気にならなくなるはずと予想しておきます。

また、PICSに反映される情報は今のところタイトルと画像ファイルだけです。Flickr2picsでは、Flickr APIを用いて画像に付加されたDescriptionやTagsなどの情報も取得していますが、PICSのAtomPPのインタフェースにそれらを追加する機能がないので反映しようがないためです。リバースエンジニアリングすれば見つかるかもしれません。これができると本当は面白いのですけれどね。

2006-01-12追記:
ひょっとしてdc:subjectでいいのかもと思った。後で試してみよう。

試してみたけど、×だった。XML::Atomでdc:subjectを複数追加するのが面倒な感じがした。

Jan 4, 2006

livedoor PICSでオリジナル画像を取得する Bookmarklet

Flickrの劣化コピーとして一躍有名になったlivedoor PICSですが、アップロードしたオリジナル画像にアクセスする方法が提供されていないようなのでBookmarkletを作ってみました。

PICS enlargement

上記リンクを右クリックなどしてブラウザのお気に入りなどにブックマーク登録しておけば、livedoor PICSのページを閲覧中に元画像を表示することができます(新規ウインドウが生成されます)。

ちなみにlivedoor PICSでは、一画像を5種類のサイズで表示できるようです。Flickrにはこれらに加えてLargeサイズがあります(Flickr: Help: Photos)。オリジナル画像が小さい時にはLargeサイズが存在しない場合もありますけど。

上のBookmarkletは、単純にページに含まれるMediumないしLargeサイズの画像URLをOriginalサイズのURLにコンバートして表示するものです。

2006-01-11追記: 当初PICSの画像ファイルの拡張子は「.JPG」「.jpg」などアップロード画像と同じものが付いていましたが、いつの間にやら「.1」のように変更されていました。Bookmarkletもこの変更に対応しました。

年末年始

この年末年始は降雪を過剰に危惧して自家用車ではなく新幹線で帰省してみました(東京⇔岐阜羽島)。

いろいろありました…。

元旦は親戚まわり。父方の親戚宅ではmonotonicに従兄弟の子供らが育ったり増えたりしているようです。こちらの出費も単調増加で馬鹿にならないことになってきました。母方の親戚宅では、昨年祖父が亡くなって祖母が一人暮らしなのですが、また食い切れない量のお節料理を作っていました。例年祖父が用意していた掻きたての鰹節と寒天がない事実(私を含め孫たちが大喜びで食べていたので祖父の年中行事になっていました)がやはり何か寂寥感のようなものを感じさせます。

さて二日、三日と比較的近くにあるモール、カラフルタウン岐阜に出かけました。二日は映画を見るつもりで、前もってチケットもTOHO THEATER ONLINEで購入しておいたのですが、年始特有の異常な交通渋滞に見舞われ、シアターに着いたのは上映開始30分後。キャンセルもしようもないし、かと言って途中から観る気にもなれず、腹に据えかねてTears For FearsのCDを買ってみたり、ふて腐れてピザ食ってみたり、拗ねてTOYOTAのMusic Playerに試乗したりしていました。要は楽しみました。三日は性懲りもなく渋滞に捕まりに行き(ただしルートを変えたので前日ほどではなく)、食料の買い出しなど。

休みも終わりかーと思っていた三日の深夜にはこのブログを管理しているサーバが落ちました。バックアップしていなかったので死を覚悟しました。はてなダイアリーを避難所にしようと思ってテンプレートを眺めていたらつい二時間ほど前に復旧していたようです。管理者さまには大感謝です。これからはバックアップすることにします、FlickrやGoogle Baseにね。

いろいろ書きたいプログラムもあったのですが、岐阜と東京とでは時間の進み方がまったく違うようでほとんど手がつきませんでした。

四日の朝に岐阜羽島駅から新幹線で東京駅、東京駅から山手線で秋葉原駅、そして目の前にダイビル。実家から2時間半あれば職場に着いてしまうようです。ひょっとして通勤圏では? と勘違いさせられる(いやそんなはずはない)、そんな年末年始でした。

About Me

My Photo

つくばで働く研究者LV15

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com