［データベース設計編］テスト・データでの性能評価を信用してはいけない

　データベースを設計する際，その処理性能は常に注意すべき課題である。机上の計算ではなかなか処理性能を読みきれないので，本格的な開発が始まる前にテスト環境を構築し，性能評価を行うのが一般的だろう。ただ，テスト環境の性能評価に多くの時間を費やしても，十分な配慮がないと実際のシステム性能との間に乖離が生じてしまうので注意したい。

データの偏りが違うだけで性能差

　性能評価を行う際，処理方式の違いには目が行き届きやすい。例えば，「1秒間にX件の更新を行う必要がある」とか，「1回の検索でX件の抽出を行いそのレスポンス時間が1秒未満である」といったことだ。こうした処理方式の違いを洗い出し，それぞれごとに性能評価を行っているケースは多い。

　一方で，テスト・データの配慮に欠けるケースが少なくない。配慮に欠けたデータを利用して性能評価を行っても，その評価結果にはあまり意味が無い。例えば，レコードに含まれるデータ値の偏りの違いだけで，SQL文の処理時間は大きく変わることがある。なぜなら，RDBMSは同じSQL文を実行したとしても，対象データベースが違えば，実際の処理手続きは変わってしまうことがあるからだ。

　RDBMSは，アプリケーションからSQL文を受け取ると，そのSQL文を解釈し，ディスク上に存在するデータにどのようにアクセスするのが効率的かを判断する。そして，そのSQL文の処理手続きである「実行プラン」を作る。同じSQL文であっても，インデックスの有無，テーブル・サイズ，データ値の偏り，などによって実行プランは変わってくる。実行プランはRDBMSの挙動そのものなので，テスト環境と本番システムで実行プランが違うと，テスト環境での性能評価結果は参考程度にしかならない。

　一つの例を紹介しよう。販売実績テーブルを顧客IDで検索し，顧客ごとの販売金額を集計するSQL文の性能を評価した例である。このシステムの販売実績テーブルは100万件のレコード，顧客数（顧客IDの種類）は1000人が想定された。そこで，テスト環境では，1顧客当たり1000件の販売実績レコードをテスト・データとして作成することにした。レコード数が100万件に達するので，販売実績テーブルの顧客IDにはインデックスを作成し，指定された顧客IDでの検索性能を高めることにした。そうしたこともあり，テスト環境での性能評価は要件を満たすものであった。

　性能面の問題は発生しないと判断し，本番システムのデータベースを開発して運用に入ったのだが，カットオーバー後の本番システムの性能はテスト環境より低く，期待される性能に達しないことが判明した。

　なぜ，このようなことが起こるのだろうか。本番システムのデータを分析してみると，100万件のレコードの顧客IDは特定の顧客（100人程度）で占められていた。販売売上のほとんどは，一部の顧客によるものだったのだ。これは「パレートの法則」（全体の数値の大部分は，全体を構成するうちの一部の要素が生み出している）といわれるようなもので，このシステムの場合，全体の1割（1000人の顧客のうちの100人）程度で，販売実績レコードの8割（80万件）近くを占めていた。

　こうしたデータベースでは，（販売実績の多い）顧客IDで検索するとインデックスが機能せず，おそらく全件検索になる。だから，インデックス検索が有効に機能していたテスト環境より性能が低くなってしまった。

　テスト環境を構築する際，データの偏りを考慮していれば，こうした事態にはならなかったはずである。データに偏りがあると分かっていたら，設計上別の対策を施すことも可能であったと思われる。

　ここではデータの偏りだけを取り上げたが，業務特性によってはそのほかにも考慮すべきことがあるだろう。