虎塚スマートフォン用の表示で見る虎塚この広告は、90日以上更新していないブログに表示しています。DB2さんの勉強会に初めてお邪魔してきました。https://www.ibm.com/developerworks/wikis/display/clubdb2/146非常に面白く、勉強になりました。備忘メモをupしておきます。(内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。>関係各位)本編(追記)発表資料にリンクしました。http://d.hatena.ne.jp/mickmack/20120714/1342246442ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。トレードオフうまい話には裏がある。論理1つ目は、物理リソースと論理的な一貫性とのトレードオフなどのことです。システムが扱うデータ量は増える一方のため、たとえばセキュリティなどの要件と違い、パフォーマンスの要件水準は上がり続けるという特徴があるとのことでした。そのため、トレードオフの話からは逃げられないという話です。手続き型の呪い「魂を重力に引かれている」的なアレファイル≠テーブル2つ目は、手続き型言語による世界の見方/考え方やマインドセットが、DBを使う上での足枷になるという話です。現在でも最初に学ぶ言語としては、手続き型言語が圧倒的に多いでしょう(20年くらい経てば変わるかも、とミックさんはおっしゃっていましたが...)。最初に覚えたモノの見方は、人に大きな影響を与えます。SQLやRDBは、手続き型ではなく、集合の世界です。DBを上手く使うには考え方を切り替える必要がありますが、これが難しいという問題があるそうです。(この件については、下記の質疑応答メモにある「ぐるぐる系」と「ガツン系」の説明をご覧ください)「手続き型の考え方では、DBテーブルをファイルと捉えてしまいがちですが、あれは集合です」というお話もありました。ストレージに触る者は不幸になるディスクに触ったら負けかなと思ってる3つ目は、1つ目のトレードオフの問題から派生する話題ですね。本編では、これらの詳細について具体的に説明してくださいました。資料が公開されたらリンクします。質疑応答メモこちらは公開されないのではないかと思うので(あまりにもったいないので)、長くなりますが詳細を書きます。ボトルネックはI/Oでしょうか?回答CPUがボトルネックになるでしょう。理由として、I/Oがいくら高性能になっても、処理する必要があるデータの量は減らないからです。DBのアプライアンス製品では、実際にCPUがボトルネックになっています。一方で、データの転送量を絞るインテリジェントな機能を持つデスクも登場しています。発表に出てきたDBアクセスの「ぐるぐる系」と「ガツン系」の定義を今一度確認させてください。※DBのテーブルをファイルと同じだと誤解して、ファイルにアクセスするときのようなループ処理をしてしまうと、ハードウェアやCPUの性能改善の恩恵を受けられない、というお話がありました。回答ぐるぐる系とは、短いSQLをループで回し、直列実行する処理のタイプを指しています。アクセスする行数は問いません。系とは、1つのSQLで、必要なデータをすべて取ってくる処理のタイプを指しています。その後、アプリケーション側でループを回すかもしれませんが、それはここでは考慮しません。同期などでたしかにその問題は起きますが、相対的には小さい問題だと思います。多くのインスタンスを並べられれば、Hadoopの方が強いでしょう。系を使っても共有デスクが残る限りは、シェアードナッシングの方が強いです。※ミックさんから、「Hadoopを使うような処理では、データをまとめるところで時間がかかることはないのでしょうか?」という逆質問がありました。大きな問題にならないように、少しずつまとめるとのことでした。その5質問ぐるぐる系の処理が遅い理由として、資料に挙げられていたもの以外に2つ考えつきました。1つ目はSQLへの値のバインド、2つ目はネットワークのレイテンシです。これらは理由として妥当でしょうか?回答はい。どちらもオーバーヘッドによる原因ですね。ローカルでの通信など、ネットワークの遠さが問題にならない場面では、前者のパースの話が、より問題になるでしょう。