Packages|Sourcesのインデックス

Hackathonの続き。 SQLで毎回既にあるかどうかチェックするのが遅かったようなので、最初に既存の情報をロードして、python の dictおよびsetでチェックするようにしたらだいぶ速くなった。 最初、dictをdictのkeyに使おうとしたら使えなかったので、dictをstrにしたのをkeyにしていたら、入力のパスによって stringになっている時 (e.g. 'foo')と、unicodeになっている時(e.g. u'foo')があって全然keyとしての役目をはたしてなかったりするようなしょぼいバグがあったり。 初期状態からのロードは、大きいPackages.gzとかだとやはり10分とかかかるけど、更新ならせいぜい1〜2分になっているようだ。一日分もだいたい20-30分くらいにおさまるようになった。これならなんとかなるかな。今のところざっと1日で4〜5ヶ月分処理できているペースなので2週間ほどで全部 index できそう。 indexのdbファイルも2ヶ月分くらいつっこんで 120MB程度。300-400MBくらいになるかな。appengine使う時は ModelのEntityになるからもっと容量が必要になりそうだなあ。 あとはCGIかservletとして動かすようにしないと。

App Engine Hackathon

土曜日はofficeでApp Engine Hackathon。
講義としてはスケールする Web アプリを書くにはと製品レベルの Web アプリを書くにはでした。基本的にはGoogle I/Oのセッションを日本語で説明するかんじで、AppEngineつかう人はぜひ知っておくべき情報です。
あとはひたすら各自でコーディング。
昼と夕方に弁当がでました。

Software Freedom Dayということもあり(?)個人的には最近放置していたsnapshot.debian.netのインデックスをなんとかしようとscratchから作り直し。いままでのversionは pdumpfsのlogをよんで、更新されているdebに関して情報ととりだして packageごとのPackagesとSourcesをつくっていました。かなりad-hocなruby scriptで、生成されるものもそのままPackages, Sourcesなのでわかりやすいことはわかりやすいけど、いかんせん量がおおすぎてとりまわしが難しかったのです。ファイル数が約55万、ディレクトリが約24万、トータルで1.6GBほど。新しいディスクやマシーンにコピーしようとしてもファイル数が膨大すぎて何時間もかかってしまうし。
ちなみに現状のsnapshot archiveはこれくらい

$ df -h /archive/
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 4.5T 3.7T 613G 86% /archive

というわけで次世代ではなんらかのdatabaseを使おうと思っていたのでした。コピーの手段も pdumpfs から cp -a --link + rsync に変更してしまっているので、そのままじゃ動かないし。
App Engine の Hackathon なので App Engine を使うことも考えたのですが、なんといっても量が多いのでquota(500M)に収まらないんじゃないかと思い、とりあえず python + sqlite でコーディング。実用的なものをめざしつつ、サイズが小さくおさまりそうなら App Engine版をつくることを見据えた選択をしました。
最近 SQLとかさわってないので思い出しつつ、いくつかはまるところがあったり。
sqlite で string な column に'1.0'をつっこむと1になってしまうとか。'1.0 'とかにするとよさげ。
とりあえずそれっぽいところまでできたのですが、なんせ量が多いのに対しperformance(特にindexing)がいまいち。
そもそも 2005/03/12 (残っているなかで一番古いやつ) ですら、一日分だけで Packages.gz+Sources.gzが 約220ファイル、延べ47パッケージエントリ、gzipされてるファイルで90Mほど、Packages.gzとSources.gzをpython-deb822で全部scanするだけで7分ほどかかります。
つくったindexerではできるdbファイルがsql tableの作り方を工夫して無圧縮で約100Mほどまでにできたのですが、しかしindex構築するのに数時間かかってしまっています。dbファイルとhddに置いてたらかなり遅かったので/dev/shm(tmpfs)以下に置くようにしたら少しは早くなったのですがそれでもまだまだ遅いです。大きめのPackages.gzだとひとつのPackages.gzファイルだけで10分～20分とかかかるかんじ。
現在 1288日分あるわけで、1日処理するのに4-5時間以上かかるとすると、全部のindexをつくるのに1年ほどかかってしまいそうです。もっと高速化しないとなー。
やはり全スキャンはやめて以前みたいに更新ログから更新分だけを処理するようにしないとだめかな。
社内にあったらMapReduceでばばんとできるのになー(Google脳…)

ESPer2008

未踏ソフトウェア創造事業関係者が集まるESPer2008に参加してきた。
一番驚いたのは、未踏ソフトウェア創造事業の英語表記が「Exploratory Software Project」から「The MITOH」に変わったらしいということ。
そういえばなんか未踏iPediaなんかできていたのか。IPAは○○iPediaが好きだな…

しかし今日はエンジニアの未来サミットとかぶっていたのね。takesakoさんはESPer2008に参加しつつUstream.TVの中継をみていた。さすが。

OpenSource協議会 System iセミナー と 裏Hackathon

今日はIBM飯倉にOpenSource協議会 System i主催の『ここまで来た企業情報システムのオープン化!』最新技術動向・事例セミナーで、「次世代Webプラットフォームにおける三つのC 〜 Client、Connectivity、そして Cloud」というタイトルでしゃべってきた。 他の会社の講演もあったけど、さっさと戻って裏Hackathon。本当は木金土と2泊3日で Hackathon だったのだけど、この用事のためにいけなかったのだ。そういうわけでこの二日間は、いけなかった人数人と一緒に会議室にこもって 裏Hackathon していた。 今回は春に20%でちょろっと作ってほったらかしにしておいたシステムを改善をめざした。完璧にはほど遠いけど以前よりはだいぶよくなってきたかなー。やりはじめるといろいろやりたいことがでてくる。普段やってないあたりなので、いろいろつまづくところもあったりもしたが、楽しい2日間であった。

NRI ABCIセッション

今日は丸の内へいってNRIのABCI(Advanced Business Creation Initiative)セッションにて講演。

概要: ソフトウェア開発においては、エンジニアの技術力の差が大きく効いてきます。変化の激しいソフトウェア業界で生き残っていくためには、自分自身がどのようなエンジニアになることができるかが重要となります。 フリーソフトウェア・オープンソースソフトウェアの世界で活動してきたソフトウェアエンジニアとして、どのようなことをしてきたか、またその時どのような判断をしてきたかなどについてお話しします。

というかんじのネタで1時間ほど。基本的には昔話をベースにMy Job Went To Indiaの格言を引用しつつどうあてはまるかとかを話していました。 気になった人は本を読んでみてください。 そういえば会場について総合受付のところで「ぐーぐるの鵜飼ですが」といったら「ぐるぐるですか」とかいわれたよ?