パフォーマンス理解の基礎 [Database]
パフォーマンス分析はそれなりに広い知識が求められるので、体系立てて学ぶ必要があります。
- 作者: エンコアコンサルティング
- 出版社/メーカー: 翔泳社
- 発売日: 2006/07/07
- メディア: 大型本
この本はパフォーマンスの基礎を学ぶにはとても良いと思います。
RDBMSで動いている限りここで語られている原理原則は同じなので
応用が利きやすい内容だと思います。
チューニングのゴールはとても重要です [Database]
私の乏しい経験で恐縮ですが、チューニング作業のキモはゴールの設定にある、
と思っています。
というのも例えば
「処理Aが今30分かかるんだけど、何とか10分で終わるようにしたい」
というオーダーであれば、それが10分で終わりさえすれば終了です。
うまくすると1時間くらいの作業で事足りてしまうこともあります。
ところが一番多いのは
「体感で処理に時間がかかっていると思う。できるだけ早くしてくれ」
というオーダーです。
これはどの処理をどれくらい早くすればいいのか分からないので困ります。
当然コストなんて見積もれません。
所謂デスマーチに多いのはこのタイプ。
なので慎重にゴールを定める必要があるのですが、後者のケースは火の手があがり
燃え広がって通常の消火プロセスでは二進も三進もいかなくなってから声がかかります。
ゴールを決めて、など悠長なことを言っている場合ではないことがほとんどです。
必然的に偉い人から「とりあえず突撃」という命令が下り、延々と遅延箇所を
探し続けることとなります。恐ろしい。
そういった燃えているDBを消火させる方法は一番良いのは短期間でお客様に満足頂く
性能指標をたたき出すこと、なんですがこれはなかなか達成できません。
よくある終了パターンは一定期間（例えば2週間）は頑張ってある程度の改善結果を出し、
そろそろ現実的な解(例えばAPロジックの見直し、我慢する、機能制限、リソース追加など)
を検討して先に進む、というものです。
大体このフェーズではお客様温度が高いケースがほとんどですので、一定期間で
どれだけチューニングができるかがポイントとなります。
この結果がそれなりに出ていれば温度は下がります（多分）
現場からするとボトルネックを探して潰す、という作業は変わらないのですが、
正解でも政治的決着でも終わる目処を立てないといつまでも抜けられないので
最初にどんなパターンになりそうなのかおおよそシナリオを考えておきましょう。
頑張る期間が2か月であったとしても、先が見えない2か月と終わりが想定できる
2か月では気持ちの持ちようが違います。
綺麗ごとかもしれませんが、私がチューニング作業時に気を付けていることでした。
岡崎市図書館の事件について考えてみた [Database]
昨日初めて目にした事件。twitterでもつぶやいたりしたけど、一言で感想を言えば「怖い」。
何が起きたのかはlibrahack.jpを見てもらえればわかりますが、
ユーザビリティに乏しい公共サービスからデータを取り込んで
自分用にカスタムしたWEBを作ろうとしていらっしゃいました。
自サイトにはIP制限をかけて自分しか使わないようになっていましたが
問題はデータの取り込み時にDDoS攻撃をしていると岡崎市または保守ベンダーに
認識されてしまったようです。
問題になっているのが、秒1回、計2000回のリクエストがアタックかどうか。
個々のリクエストの負荷が過剰に高いのではないか説が有力なようです。
（このあたりは生島さんのblogの考察がわかりやすいのではないかと思います）
開発元の三菱系ITベンダー(MDIS)が設計や運用上のミスを棚に上げて刑事告発したのでは
など、いろいろときな臭い噂も立っております。
さて、私の感想「怖い」ですが、言わずもがな自分のWEBアクセスがDDoS認定され
犯罪者になってしまうことが怖いです。
WEBサービスが当たり前に提供される世の中ですが、この事件が警察でのスタンダードになり
うかつに開発、利用できなくなるようにだけはなってほしくありません。
さてデータベース屋として思うのが、このようなシステムは実はたくさんあるのではないかということ。
ある処理をするとCPUが高騰する、接続数が少ないのに処理が終わらない、など
結構日常的に聞く話です。
負荷テスト実施や障害のために日頃から資料採取をしておくといった基本的なことを
徹底できるよう啓蒙していきたいと思います。
＃このblogからはうまくtrackbackが飛ばないです・・・
http://d.hatena.ne.jp/Sikushima/20100621/1277104805
http://mimizun.com/blog/2010/06/post-654.html
表の結合 [Database]
Nested Loop
片方を駆動表と呼ぶ。駆動表を一行読むたびにもう一方に条件に該当するレコードが
無いか読み込む。駆動表の検索が終わるまで実行
駆動表のレコードは必ず1回は読み込まれる。もう片方は何度も呼ばれる可能性がある。
Sort Merge
2表をキー値でソートしてマージ、先頭から条件に該当するレコードを探す
Hash Join
キー値からHashテーブルを作成。Hashしていないテーブルから該当レコードを抽出、
Hashテーブルからレコードを探す。Hashのシノニムが発生する。
知らなかった単語 [Database]
恥ずかしながら告白です。
英語で技術文書を読んでいたところ、知らない単語に遭遇しました。
データベース系の文書なので当然専門用語が出てくるわけですが。
私自身は英語はめっちゃ得意というわけではありませんが、
海外希望しているくらいなので嫌いではなく、むしろ文書解読なら
それほど難はないと思っていたんです。
が。
この単語知らね。。。と思って辞書を引きました。
indices indexの複数形
。。。。
マジスカ。
index -> indexesだけだと思っていました。
indexなんてリレーショナルデータベースでは基本的な単語。
なのにその複数形を知らなかったなんて。
今デスクで使っている辞書は中学生の頃に買ってもらったNew Collegiateですが
10年ぶりくらいに赤線入れました。
もちろんindicesの見出しに。
データベースは生きている [Database]
私はデータベースは生きていると思っています。
データベースは何かを聞かれると、論理的に矛盾しないように答えを返さなければなりません。
それは聞きたい人がやってくる時間は常にそうしなければなりません。
それは動き続けなければならないということです。
ところがデータベースは時々調子を崩します。
論理的に知識が整理されていなかったり（不整合）、
思い出すのに時間がかかったり（パフォーマンス劣化）、
気絶したり（システムダウン）、
します。
データベースは自律的に考えること、状況を判断することはできないので
人間が外から監視してやる必要があります。
時々は話しかけてあげてください（監視コマンドなどで）。
犬だって飼ってきて注射して基本的な躾をしたらあとは放っておいていいわけではないでしょ？
餌（電気）は勝手にデータベースには供給できるけど。
定期的に面倒を見てあげないとわからないことってたくさんあると思います。
好み（適切なパラメータ）やついてしまった肉の量（データの増加）とか。
そういうものって結構大事です。
「いきなり遅くなった！」とか「領域がパンクした！」とか
監視さえしっかりしておけば回避出来る問題はたくさんあります。
「一般的な設定を教えてください」と言われてもシステム依存のものがたくさんあります。
ということで監視を甘く見ちゃあいけません、ということでした。
データベース学的なものも生物学のモデルを嵌めてみたらぴたっと当てはまったりして。
設計書を作る時 [Database]
データベースをやっていると色々な設計書をごらんになることが多いと思います。
私も見たり書いたり色々ですが、書くときはWORDを使いますか？EXCELを使いますか？
私はWORD派です。
課題管理表などはEXCELで作ることが多いのですが、
どうも設計書はWORDで作ってしまうことが大半です。
私の周りはEXCEL派が多いのですが、異端なんでしょうか・・・
EXCELを使うメリットとしては私は表があると思います。
課題管理表などの表構造だけで構成されるものはそれでいいんですが
設計書などは「なぜその値にしたのか」といった根拠を入れる必要があります。
そのためにEXCELを使うと微妙な改行などを制御しずらいんですよね。
またセル単位で計算するようなこともあまり無く、EXCELはあまり使いません。
ベンチマークあれこれ [Database]
現在色々あってTPCについて紐解いています。
昔の部署（Oracleデータベースのサポート部門）に居たときもTPCライクなベンチマーク測定は
やっていたのですが、今は各ベンダーが使っているクライアントプログラムに現在興味の方向性を
定めて色々調べています。
関係代数 [Database]
とあるblogに
「外注さんにAP作成をお願いしたけど、OracleMasterGold持っているくせに
内部結合と外部結合の使い分けができないなんてどういうことだ？」
というエントリーがありました。（もうURLは忘れてしまったけど）
私はOracleMasterPlatinumを持っています。
しかし実はインフラ側の知識ばっかりで実はSQLをどう書くか、
APロジックとしてはhogehogeが一般的である、
といったDatabaseより上の層のことはあまりよく知りません。
その外注さんを擁護するつもりはないけど
＃その人はAP作成スキルを採用条件にされたはずですし
＃それを満たせないのは雇用元、外注さんの本人のプロ意識の問題だから。
＃できないなら素直にできない、というのもプロとして当たり前ですよね
OracleMasterという試験はあくまで知識であってスキル保証ではない
という実質的な面を理解してほしいなあと思ってみたり。
たとえ実技試験を通ったとしても、現場で使える技術が極めて高いわけではありません。
むしろ現場では場数だったり、人間的なスキル（コミュニケーション、発想力）
がものを言います。
何を言いたかったかというと、俺もSQLのことくらい知っておかねば、
と思ったので関係代数の勉強でもしてみようと思います。
大学時代に代数は得意で卒業論文もそれがらみだったんですけどね。
方向性 [Database]
他のエンジニアさんのblogなどを見ていると結構頻繁に更新していて
かつ内容が濃いものが多いですね。
私のようにダラダラとやっているところは少ないような・・・
日報に近くなるようにやったこととか書いていこうかなと思っていますが、
個人が特定されそうなことばかり（言ってしまえば奇異な行動）が多いので
どうしようかなあ、というところです。
ここ数日は新しい部署でひたすら勉強の毎日です。
http://www.microsoft.com/japan/technet/prodtechnol/sql/2005/exercises.mspx
にある自習書をひたすら読むという苦痛に近い勉強ですが、
義務づけられている教育プランとチェックポイントがあるので仕方がないのでがんばってます。
RDBMSの部分はOracleに通ずるので問題はあまりないのですが、BIに関する部分は
Oracle部署ではやっていなかったので結構つらいものがありますね。
OracleもBIを売り物にしていましたが、うちの会社ではあまり売れてないなあ
というのが正直なところです。そうすると人的リソースも割り当てられないという構造でした。
さて昨日今日はちょっと原点に返ってCoddの論文に久しぶりに目を通しました。
http://www.acm.org/classics/nov95/toc.html
やっぱりRelationalといえばこの論文。
DBの根源をたどる仕事になりそうなので、この原点は忘れてはならない訳です。
今月中には70-431をとらなければならないんですが、まだ手をつけていません。
どうしよう・・・
