講義としてはスケールする 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脳…)
No comments:
Post a Comment