「達人が語る こんなデータベース設計はヤダ！」へ参加してきました

Database Event

あの『達人に学ぶDB設計 徹底指南書』を書かれたミックさんが講演されると聞いて、Club DB2さんの勉強会に初めてお邪魔してきました。

非常に面白く、勉強になりました。せっかくなので、備忘メモをupしておきます。

（内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。＞関係各位）

本編

（追記）発表資料にリンクしました。

ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。

1つ目は、物理リソースと論理的な一貫性とのトレードオフなどのことです。

システムが扱うデータ量は増える一方のため、たとえばセキュリティなどの要件と違い、パフォーマンスの要件水準は上がり続けるという特徴があるとのことでした。そのため、トレードオフの話からは逃げられないという話です。

  • 手続き型の呪い
    • 「魂を重力に引かれている」的なアレ
    • ファイル≠テーブル

2つ目は、手続き型言語による世界の見方/考え方やマインドセットが、DBを使う上での足枷になるという話です。

現在でも最初に学ぶ言語としては、手続き型言語が圧倒的に多いでしょう（20年くらい経てば変わるかも、とミックさんはおっしゃっていましたが…）。最初に覚えたモノの見方は、人に大きな影響を与えます。

SQLやRDBは、手続き型ではなく、集合の世界です。DBを上手く使うには考え方を切り替える必要がありますが、これが難しいという問題があるそうです。（この件については、下記の質疑応答メモにある「ぐるぐる系」と「ガツン系」の説明をご覧ください）

「手続き型の考え方では、DBテーブルをファイルと捉えてしまいがちですが、あれは集合です」というお話もありました。

  • ストレージに触る者は不幸になる
    • ディスクに触ったら負けかなと思ってる

3つ目は、1つ目のトレードオフの問題から派生する話題ですね。

本編では、これらの詳細について具体的に説明してくださいました。# もし資料が公開されたらリンクします。リンクしました。

質疑応答メモ

こちらは公開されないのではないかと思うので（あまりにもったいないので）、長くなりますが詳細を書きます。

その1
質問
もし物理層の技術でI/Oボトルネックが解消されたら、次のボトルネックは何でしょうか？ やはりボトルネックはI/Oでしょうか？
回答
CPUがボトルネックになるでしょう。理由として、I/Oがいくら高性能になっても、処理する必要があるデータの量は減らないからです。DBのアプライアンス製品では、実際にCPUがボトルネックになっています。一方で、データの転送量を絞るインテリジェントな機能を持つデスクも登場しています。
その2
質問
発表に出てきたDBアクセスの「ぐるぐる系」と「ガツン系」の定義を今一度確認させてください。

※DBのテーブルをファイルと同じだと誤解して、ファイルにアクセスするときのようなループ処理をしてしまうと、ハードウェアやCPUの性能改善の恩恵を受けられない、というお話がありました。

回答
ぐるぐる系とは、短いSQLをループで回し、直列実行する処理のタイプを指しています。アクセスする行数は問いません。ガツン系とは、1つのSQLで、必要なデータをすべて取ってくる処理のタイプを指しています。その後、アプリケーション側でループを回すかもしれませんが、それはここでは考慮しません。
その3
質問
シェアードデスクでもメモリに載せれば速くなるといいますが、結局ロックの競合がメモリ上で発生するので、だめではないでしょうか？
回答
同期などでたしかにその問題は起きますが、相対的には小さい問題だと思います。
その4
質問
Hadoopなどでぐるぐる系処置を並列に実行する力技がありますが、その方法とガツン系処理では、どちらが勝つでしょうか？
回答
分かりません。多くのインスタンスを並べられれば、Hadoopの方が強いでしょう。また、ガツン系を使っても共有デスクが残る限りは、シェアードナッシングの方が強いです。

※ミックさんから、「Hadoopを使うような処理では、データをまとめるところで時間がかかることはないのでしょうか？」という逆質問がありました。大きな問題にならないように、少しずつまとめるとのことでした。

その5
質問
ぐるぐる系の処理が遅い理由として、資料に挙げられていたもの以外に2つ考えつきました。1つ目はSQLへの値のバインド、2つ目はネットワークのレイテンシです。これらは理由として妥当でしょうか？
回答
はい。どちらもオーバーヘッドによる原因ですね。特に、ローカルでの通信など、ネットワークの遠さが問題にならない場面では、前者のパースの話が、より問題になるでしょう。ただし、一番の問題ではありません。
その6
質問
デスクのサイジング法で、「CPUだけ見てもだめ」という話がありましたが、結局どうやればいいんでしょうか？
回答
答えはありません。理由として、まず、ストレージの情報はベンダの内部に閉じていてなかなか出てこないからです。また、DB性能の計測の指標やその見方の確立された方法論が、CPUのそれほどありません。あれば教えてください。
その7
質問
安いマシンを買ってしまって、後から性能問題で苦労されたことってありますか？
回答
あります。選択のポイントとして、DBサーバはCPUをケチっても構いません。せっかくCPU性能が良くても、DBサーバだとフルに使えないからです。あと、32bitマシンはもうやめましょう。
その8
質問
大量データ処理にはそもそもDBMSが向かないというお話がありました。であれば、そういった処理をしたいときにはファイルシステムなどの上で自前実装するべきなのでしょうか？
回答
要件次第です。そうまでしてやらなければならない強い要件が存在するならば、もちろんやるべきです。しかし、DBMSを使うメリットはいろいろあります。
その9
質問
お好きなO/Rマッパー、きらいなO/Rマッパーを教えてください。
回答
好きなO/Rマッパーはありません。性能まわりの仕事をしていると、フレームワークのようなものが、内部でぐるぐる系の処理をしていたりして…（以下略）。しかし、使うメリットがコストを上回るなら当然使うべきです。使うことで失われることや抱える問題も認識しておくのがエンジニアだと思います。

※DBFluteは中でぐるぐる系の処理をしていないそうです。

その10
質問
DBをオンメモリにしても解決しない問題というのはどんなことですか？
回答
第一に、実行計画の揺れです。それから、通常時と縮退時との落差です。たとえば、アクティブ-アクティブ構成の縮退時に、データがメモリに乗り切らず、サービスが不安定になるといった問題がありえます。
その11
質問
更新系の処理の速度も、メモリにのせることで解決するのでしょうか？
回答
更新といっても、検索してから更新しているので、検索部分は速くなります。ただ、問題がなくなることはありません。
その12
質問
ぐるぐる系の処理を見たことがないのですが、どういった場所に存在するのでしょうか？

※「それは幸せですね」「素晴らしい設計をしていますね」といった声が…

回答
バッチです。なぜバッチかというと、オンライン処理のモジュールを使い回しているケースがあるからです。また、内部でSQLを発行するモジュールをそうと知らずにループで回していたり、それを多重に回していたりすることもあります。

まとめ

そんな感じで、あっという間の2時間でした。本当に勉強になりました。

ちょうど1年前、複合主キーについて無知を晒して恥をかきましたが*1、あの時にコメントくださったjfluteさんのLTを聞けたのもラッキーでした（LTじゃなくて40分くらい聞きたかったです）。

DBと一言でいってもレイヤーは多層ですし、考えないといけないことは沢山ありますね。上手く使えるように勉強しようと思います。

発表されたお二方、Club DB2の皆さん、ありがとうございました。

*1:複合主キーを避けるべき理由 - 虎塚