未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

YAPC::Tokyo 2006

wifiトラブル中
つながりました。
YAPCはスタッフの愛で支えられているような感じがする。id:jkondoid:naoyaid:miyagawaさんにご挨拶。素晴らしいカンファレンスありがとう。

Perl 5.8 and Unicode

質疑応答:shiftjisで\(0x5C)はどのように変換されるか?¥(0xA5)か?
回答:ASCII部分はいじっていません。

Perl 6 update

Perl 5のシンタックスをすっきりさせて、若干の演算子を追加した。

Legacy Encoding

スーツ姿というのが違和感をかもし出していた。(むむむ)プレゼン資料も高橋メソッドではないので、場違い感がただよう。

昼食

まつもとさん、江渡さん、わかとのさん、西田さん、森山さんと、中華。(懇親会会場というのがあれであるが)

Haskell

昨日のPugsで衝撃を受けたので、お話を聞く。関数型言語というのはなかなか面白いっすね。http://www.haskell.org/haskellwiki/Haskell

Hatena Bookmark

Hatena Bookmarkのサーバ数は17台(アプリサーバ10台、DB6台)。tmpfsを使っている。今後は分散ファイルシステムを利用したい。IT企業からHighTech企業になりたい。
mixiの運用のようにMySQLを手で分割(水平、垂直)していくとアプリがどんどん複雑化していくので、どうにかこうにかクラスタファイルシステムみたいなのが欲しくなる。IT企業からHigh-Tech企業になりたいというフレーズが素敵。

素晴らしいカンファレンスでした(拍手拍手)

技術的なところでの感想

やはり、mixiMySQLの運用の話と、Hatena Bookmarkでのお話が自分的にはいろいろつっこみたいところである。(日経ITProの記事:http://itpro.nikkeibp.co.jp/article/NEWS/20060330/233820/
DBの場合、最終的にはスケーラビリティが勝負みたいなものだから、それをいかに確保するかという話は、Oracle RACのようなシェアードエブリシングのクラスタRDBMSに落ち着くと思う。シェアードナッシングのクラスタは、データが急増している場合には、データのパーティショニングが難しいので向いていない。つまり、データ量が倍になったとき、半分のデータを別サーバに移行しなければならないので、常になんらかの形で移行のコストが発生する。一方シェアードエブリシングであれば、ストレージはそのままで、どんどんデータを追加していって、PCサーバーをどんどん増やすだけで処理量の増加に対処できる。
http://d.hatena.ne.jp/hyoshiok/20060208#p1でも指摘した通り、分散ロックマネージャ、キャッシュフージョン(メモリ内容をクラスタに参加しているサーバー間で共有する)、クラスタファイルシステムを前提としたRDBMSが必須となる。クラスタファイルシステムとしては、GFSやOCFS2あるいはlustreなどがOSSとして有名だが、それらとMySQLなどを組み合わせてMySQL RACなどを作れたら素敵だな(妄想はいっています)

YAPC::Asiaの感想

これだけの人を集めた、スタッフの皆様respectです。ボランティアrespectです。運営の手際のよさ素晴らしいです。発表者はもちろん300名を超える参加者の皆様もrespectです。日本のセミナーだとふつー質疑が盛り上がらないのだけど、参加されていた皆さんすごくいい質問をがしがししていてそれがまた理解を深めるという本当にいいフィードバックがあって巣晴らしかったです。最後は拍手が鳴り止まなかったもんなあ。