ClubDB2参加記録 第146回 達人が語る こんなデータベース設計は嫌だ（by ミックさん）に行ってきました。
毎度毎度、久しぶりにClubDB2に参加してきました。
ここ半年ほど、第4金曜日に夜勤が入ることが多くなり、参加したくてもできないことが多かったのですが、今回は講演者がミックさんということで、夕方に1時間早上がりをする段取りまで付けて参加しました（笑）
ミック([twitter:@copinemickmack] / id:mickmack)さんについては、前回の登壇（Welcome to Wikis)で初めてお目にかかり、その後著書を2冊ほど読ませていただきました。
特に近著 「達人に学ぶDB設計徹底指南書」については、非常に多くのグレーノウハウ、バッドノウハウ、「わかるわかる」と頷くノウハウから「えー！こんなのあり（笑）」といったノウハウを分かりやすく紹介していただき、気付ば毎朝30分ｘ5日ほどで読了してしまいました。2時間ちょっとで読み終わってしまうとは、高い買い物でした（笑）
今回の2次会でありがたくサインも頂き、現在は後輩の課題図書として貸出中です。
この本で、前チームの若者たちが少しでもピヨピヨを卒業してくれると嬉しいものです。
達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2012/03/16
- メディア: 単行本（ソフトカバー）
- 購入: 21人 クリック: 316回
- この商品を含むブログ (24件) を見る
閑話休題。
さて、今回のミックさんの公演ですが、サイジング方面からみたDB設計がテーマでした。
話は多岐に渡ったのですが、私自身考えさせられることが多かったテーマを中心にブログにまとめようと思います。
これだけは覚えて帰ってほしい３つのキーワード
ミックさんが「これだけは！」とおっしゃるキーワード。これはそのまま掲載して、このブログを読み返すたびに気付けるようにしたいと思います。
- トレードオフ
- ハードウェアの進歩により大分変わってきたが，データベースの世界にはまだまだのこっている。
- データベースに求められる要求水準は青天井
- これは主に性能要求に関することだったと思います。
- 手続き型の呪い
- ファイル≠テーブル
- 超重要。DBエンジニアの人生を変える（笑）
- ストレージに触るものは不幸になる。
- 「ディスクに触ったら負けかと思ってる」
ミックさんの名言
前回の公演でも触れていたことなのですが、「ガリガリチューニングを頑張るよりH/Wを買うのが（多分）正しい」
特にSI案件ではこれがかなり難しいことなのですが、エンジニアとしてはかなり的を射ている言葉だと思います。先日、社内でこの考え方を話したら、参加者の皆さんが目からウロコが落ちる反応をしていました。コロンブスの卵ではあるのですが、このご時世、まさにそのとおりですよね。
具体的には、以下のような対処がこれに当たると思います。
- メモリを積む
- 良いストレージ製品を買う
- パーティショニングオプションを買う
ディスクに触ったら負け？
このキーワード、インフラエンジニアとしてもろに食いつきました。「そうなの？」って。
でも、世界の大部分のシステムであれば、たしかに、インフラレイヤーをDBエンジニアに意識させたらインフラエンジニアの負けですよね。制約があるなら、最初から設計して、「こういうふうに使ってね」って説明したいものです。
でも、ケースバイケースとはいえ、メインフレームの基幹システムの分野ではディスクの物理設計、パフォーマンスをちゃんと見られないとインフラエンジニアとしては不十分だと感じる事が多いです。（私もまだまだ勉強中の身ですが）
責任分界点という考え方
ミックさんが一例としてあげていた「ビュー ⇔ テーブル ⇔ ファイル ⇔ ストレージ」の責任分界点議論、
それぞれの責任分界点を以下のように分けていました。（アプリケーションエンジニア部分はkmasu追記部分）
- ビュー：アプリケーションエンジニア
- テーブル、ファイル：DBエンジニア
- ストレージ：インフラエンジニア
この「責任分界点」とか「役割分担』という言葉って、往々にして誤解を生みやすい言葉ですよね。
私は、（誰に聞いたか忘れたのですが）「責任分担」という言葉が好きです。
一例を上げれば「インフラエンジニアとしてストレージに責任をもつなら、隣接するDBエンジニア領域を知らないと責任が持てないよね？」ということです。
ちょっと長くなるのですが、
「システム全体を考えれば、インフラエンジニアはストレージだけを見ていれば良いのではなくて、ストレージ観点でファイル（DBMS）側に入り込んでいかなければダメだし、DBエンジニアもストレージのことを勉強して、インフラエンジニアを使いこなさないといけない。あくまで、スペシャリティとしてどこまでをカバーするか、であって、隣接する分野の知識を持ち、その分野のスペシャリストを使いこなしてシステム全体を最適化するのがエンジニアとしての責務」だと思うんです。
このへんはid:megascusさんとほぼ同じ考えなのだと思いました。
酒井さんとの議論
2次会でちょっとだけ酒井さんと話をしたテーマです。
ここは後日まとめたいな〜。
検索キーがクラスターインデックスだったら、ループのほうが早いことがある？ってことを話しさせていただきました。
その他キーワードメモ
- TPC-Cは「システム構築の現場では」参考にならない。超ハイスペックストレージを使っていてサイジング無視だから
- シェアードナッシング VS シェアードディスク。パフォーマンスを出そうとすれば社アードナッシング型になるが、制約が大きい
- 全部メモリに載せちまえ（笑）
- 32bit OSはだめよ！2Gの制約。オワコン
雑談
当然ながら2次会も参加しました。
毎度ながら、終電の関係でみなさんより少し早くお暇しましたが、非常に楽しい時間を過ごすことができました。
火消し会場から登場した（笑）ミックさんに、「障害対応は血沸き肉踊りますよね〜」っていったら、「ソルジャー症候群」だって言われちゃいました。いけないとは思いつつ、やっぱりそれはだめですよね(^^; でも、自分で火をつけるところまでは行っていない（はず）なので大丈夫です！
あと、PureScaleに話が及んだ瞬間の下佐粉さんの必死っぷりが楽しかったです（失礼！）でも、私もあそこは話したくてうずうずしました。「CFやCF Linkが高速で、ほぼダイレクトメモリアクセスだから、ロック制御や更新データ制御もボトルネックにならない！（なりにくいんです！）」って。
そうそう、「「魂に重量を引かれている」的なあれ」ってところ、思ったより会場の反応が鈍かったなぁ。自分的には一番面白かったです。
