Club DB2 でゲスト講師をしました

 昨日 7/13 に渋谷マークウェストで Club DB2 のゲスト講師としてお話をさせていただきました。RDB の設計における物理と論理のせめぎあい(トレードオフ)というテーマで、前回以上に自由に喋らせていただきました。いつもながら運営の寛大な方針に感謝しています。ご参加いただいた皆様、お疲れ様でした。

 講演では説明が足りなかった部分、また質問をいただいたことで改めて自分でも考えてみたことを、少しここで補足しておこうと思います。

 

  • ぐるぐる系が悪いケース

 まず、前提としてぐるぐる系が猛威を振るうのはバッチです。オンラインでは、そもそもループ回数が少ないので大きな問題にはなりません。講演でも、最初にこのことを明示して話を進めるべきでした。前提をはしょったせいで混乱を招いたかもしれません。

 

  • ぐるぐる系を並列させるのはどうか

 ループそのものは直列だとしても、ループ自身をジョブレベルで並列させれば、立派な並列分散になります。私の拙い理解では、Hadoop はまさにそのような仕組みです。
 ただし、この並列が有効にスケールするためには、シェアードナッシング的な構成を取る必要があります。ディスクがボトルネックポイントになるケースでのぐるぐるは、どれだけループを並列させてもスケールは難しいでしょう。

 

  • 更新処理が入るとシェアードディスクがスケールしないのはなぜか

 同じデータ更新によるロック競合、というお話した問題のほかに、キャッシュの同期更新のオーバーヘッド、という問題もあります。更新が発生すれば各ノードが持っているキャッシュも更新されるため、更新処理が多くなるほどこのオーバーヘッドが多くなり、スケールしなくなっていきます。「更新処理がどの程度含まれているか」というのは業務系ベンチマークを評価するときのポイントの一つなので、皆さんも覚えておいていただければと思います。

 
 講演資料もアップしました(PDF)。また、感想を書いていただいたブログはこちらです: