WinChalow

Ping Aggregation will be dead.
http://blog.bulknews.net/mt/archives/000990.html

楽天がpingをとばすようになるので、アグリゲーションがパンクするということなようです。いわゆる"Cascade Corruption"の一種ですね。「インターネット大陸移動説」では、blogが中央大陸(楽天)を浸食する過程で、島嶼の一部が中央大陸からの雪崩にまきこまれて水没する、という説明になりましょうか。興味深い現象です。

さっそく水没したサイトがあったもようです。
http://naoya.dyndns.org/~naoya/mt/archives/001097.html

Myblog JAPANは５分間に200pingで床下浸水のもよう。
http://www.myprofile.ne.jp/blog/archive/saito/92

よく考えてみたら、pingだけでもパンクするくらいなので、楽天のblogサーバー自体は相当な負荷がかかっているはずです。blogブームは、実はサーバ屋が仕掛けてたりして…

そういえば、PingやTrackBackなどの強制リンク要請のシステムが登場する前のウェブには、強大なハブが弱小局を直接、物理的に押しつぶすようなことはありませんでした。インターネットやハブの性質が変化していることは、間違いなさそうです。いや、実に興味深い…

Software Design の今月号（５月号）にXpSQLというXMLデータベースがのっていたので買ってきました。バックエンドにPostgreSQLを使って、細粒度のマッピングを行い、XPath検索ができるというもので、平成１４年度の未踏ソフトウェアに認定されています。

この手のものは２０世紀末にさんざんやったので、前世紀の遺物と思っていましたが、いまだに未踏というのには少々驚きました。

ツリー構造情報(parent, child, next)をそのまんまPostgreSQLに格納するので、SAXパーザからのバルクロードは効率が悪そう、と思ってベンチマークを見ると1Mをロードするのに4分かかると書いてあります。リニアにいくという非現実的な仮定をしても、500Mのロードに33時間もかかる計算です。PostgreSQLは一定以上のデータ量でガックシとスピードが落ちます。実際にはロード不能と思われます。うちで使っているXMLの実データは500Mオーダーなので、採用は見送りとなりました。

検索効率の方はなかなか良好です。10Mオーダーの小規模DBにはよいかも知れません。

XMLを細粒度でRDBマッピングするシステムのキモは、ノードの付番法にあるわけですが、XpSQLではデシマル・オーダーという技法を使っています。これはちょっと面白いので、Perl+MySQLで実装してみましょう