処理経路の変化(1)

パフォーマンス問題では結構、このタイトルが原因である事が僕の経験上ではよくあります。

処理経路の変化、と一般的な書き方をしましたが、専門的な言い方をすれば、

リレーショナル・データベースにおける実行計画（アクセス・パス）の変化

という事です。

リレーショナル・データベースにおいて純粋なパフォーマンスというのは、どの経路でデータを取得するか、が全てであり、これにパフォーマンスは完全に依存しています。

例えば表のデータを全て読み取る（フル・スキャン）か、表に設定されている索引を読み取るか（インデックス・スキャン）、複数の表が対象の場合は、どのように結合をするか、といったような話です。

どういう風にデータを取ってくるか。

この経路を誤ってしまうと、パフォーマンスに多大なる悪影響を及ぼすことになります。

そしてこの経路のことを総称して、「実行計画」と言ったり、「アクセス・パス」とか言ったりします。

しかし困ったことに、この経路をアプリケーションの開発者の方々はあまり意識されないという現実があります。

例えば以下のようなSQL文（リレーショナル・データベースとやりとりする際に使用する言語）を書いたとします。

SELECT * FROM TEST WHERE COL1 = 'A';

現在のORACLEを含めた各種データベースにおいては、上記のような記述をするだけで、

　・TEST表自体をフル・スキャンする

　・TEST表のCOL1列にある索引をスキャンする

上記のいずれの経路でデータを取得するかは勝手に判断してくれたりします。

ちなみにこの勝手に判断してくれる機能の事を、オプティマイザと言います。

この”勝手に判断する”という点が問題なんです。

開発する側の立場としては、DBは単なるデータが入っている器であり、データ取得経路なんて意識する必要がない、というわけなんですが、そこに落とし穴があります。

じゃあ誰が経路を判断してるのか？

それがオプティマイザです。

そしてオプティマイザが導いたこの経路は、100%正しいという事はありえないわけです。

よく考えてみてください。

そもそもあるSQL文が飛んできて、1000通りある経路のうちどうやって最適な経路が導けるのでしょうか？

OracleやDB2、MySQLといった各種データベースソフトウェアによって多少の違いはあるものの、大きく言えばオプティマイザは”統計情報”と呼ばれる情報を基にして経路を導出します。

統計情報って？？

これも各ソフトウェアにより異なりますが、簡単にいえば

　・その表のサイズがどの程度か

　・その表の列の定義はどうなっているのか

　・その表の列内の値の種類はどの程度か

　・その表の列内の値の偏り（ヒストグラム）はどうなっているか

　　　　　　　　・

　　　　　　　　・

　　　　　　　　・

　　　　などなど、他にもたくさん

といった情報をもとに、最適な経路を導出してくれるわけです。

今日はここまで。

パフォーマンス問題論争

DBシステムにおいて、最近特によく耳にするのがこのパフォーマンス問題。

具体的に言えば、

　「なんか遅いんだけど・・・」

　「結果が返ってこない！」

　「夜間バッチ処理が今朝になっても終わってない！！」

といった類のものです。

この場合、どこに問題が生じていて処理が遅延しているのか、パフォーマンス劣化の原因箇所を特定する事が急務となります。

以下の2点のどちらか、もしくは両方に問題があるケースがほとんどだと思います。

1. DB内部の処理上の問題

2. DB外部の問題

2については、例えばネットワークが詰まっていたり、クライアント側のマシンのCPU高騰が原因だったり、そういったDBとは関係のない部分での問題です。

こちらは今回議論しません。

今回は1のDB内部の処理上の問題について考えてみましょう。

大きくDB内部の処理上の問題の原因は、以下に分類できます。

1) 処理経路の変化

2) OSリソース上の問題

3) パラメータ変更

4) アプリケーションレベルの変更

5) 設計上の問題

6) ソフトウェア、OS不具合
7) その他

上記各項目については次回以降述べていきます。

ここで重要な点は、基本的に上記以外にDB内部の処理上の問題は存在しないという事です。

つまり上記の”どれに該当し得るか”さえ把握出来れば、対応がスムーズに行くわけです。

ということは、

どれに該当するかを判断可能な情報を取得している必要がある

ということです。

いわゆる”定常監視”といったやつです。

よくパフォーマンス問題が発生した際に、とりあえず周りに怒鳴り散らすだけ怒鳴り散らすお客様がよくいらっしゃいます。

確かにそのお気持ちは痛いほどわかります。パフォーマンス問題で上層部から何らかの圧力がかかる可能性もあるでしょうから、気が気でない気持ちは察するに余りあるでしょう。

しかし怒鳴る前に、手を打ってましたか？

問題箇所がすぐに特定出来る状態に、あなたの見ているシステムはなっていますか？

そういう状態になっていないのにも関わらず、パフォーマンス問題で激怒するのは筋違いですし、議論の余地もありません。

一般の方は信じられないかもしれませんが、この業界はこういうことが本当によく発生し、原因箇所の特定すら出来ないケースが本当に多いわけです。

では次回以降、DB内部の処理上の問題について1つずつ見ていくことにしましょう。

交渉

この業種に関わらず、交渉、しかもそれが特別ハードな交渉があると思います。

DBエンジニアとして一番厳しい交渉は、トラブル対応ではないでしょうか。

家を建てたら、その家が翌年、自然倒壊することはまずありませんし、車を買ったら翌年、突然エンジンが壊れるなんてこともあんまりないでしょう。

でも構築したDBが翌日、落ちてしまう（システムとしてダウンする）ことは、お恥ずかしい限りよくあるんですね、これが。

細かい技術に関する項目やその際の交渉術を今回、書くつもりはありません。

備忘録として書いておこうかと。

それは、何があっても、自分に非があっても相手に非があっても、偶然でも必然でも、どんな状況でも、

冷静に対応すること。

決して慌てないこと。

絶対に相手の目を見て、話すこと。

たぶんこれが全てなんじゃないかと。

これが出来ないと、相手の信用は得られませんし、相手の怒りも収まりません。

そういいながら、今日もボクの目は泳いでただろうなぁ。きっと。