Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

SQL文の性能単価測定に適したパラメータの自動推定

多くのRDBMSには、実行したSQLの実行計画や性能単価を取得する機能が備わっています。SQLの性能単価を測定する際は、検索のパラメータや、テーブル中のデータのバラつきといった前提を、できる限り本番環境に近づけることが重要です。

たとえばPostgreSQLでは「EMP_NO = NULL」のように必ず偽になる検索条件を設定してしまうと、Plan Rowsがゼロになってしまい、検索処理が実行されなくなってしまいます。SQLのパラメータは、常に偽になる検索条件が、ひとつも現れないよう選ぶ必要があります。またたとえば、Oracleではカーディナリティによってアクセスパスが変わります。年齢のように複数レコードが同じ値を取りうるデータを検索する場合、全レコードの30%以下を占める値を検索条件に指定した場合はインデックスが使われますが、そうでない値を検索条件に指定した場合はテーブルスキャンが行われます。

ただ一方で、このような性能単価測定の注意事項を理解するには、RDBMSに対する高い技術的知識が必要です。本番環境の想定を理解するには業務知識も必要ですから、技術的知識と業務知識の両方を備えたエンジニアが必要になってしまいます。そんな人はそうそういません。

かといって、RDBMSの特性について何も知らないエンジニアに性能単価測定をやらせても、意味のない結果が返ってくるだけです。たとえば実行時間が過小に評価されてしまい、本番環境で実際に業務処理を流して初めて、SQLのせいで思ったより性能が出ないことが分かったりします。

これらの問題を解決するには、本番環境のデータに近い性質のテストデータや、そのデータに対する適切な検索条件を、人の手を借りずに求める必要があります。

本番環境のデータを元にテストデータを作る方法としては、DBエースやOracle Data Masking Packといったツールを使う方法があります。ですが、建屋からの持ち出せないような機密性の高いデータにこれらのツールを使っても、生成したデータをすべて人の目で確認することになってしまいます。これは、これらのツールで作成したデータが、現実世界であり得るデータなのかをツールが判断することができないことに起因します。

そのような機密性の高いデータの場合は、本番環境のあるサーバルームに測定用端末を持ち込んでSQLの性能単価を測定することになります。この場合、SQLの検索条件を前もって決めておくことはできないため、サーバルーム内でデータの内容を確認し、その場で検索条件を決める必要があります。このような機密性の高いデータは、目視での参照にあたっても運用者による監視が必要となるケースが多いため、検索条件の設定作業に長い時間をかけるのは現実的ではありません。

そこで本研究では、与えられたデータとSQLを元に、性能単価測定に適切な検索条件(SQLのパラメータの値)を自動的に推定する方法を示します。ここで適切な検索条件とは、最終的なクエリの結果に1件以上のレコードが含まれるものとします。適切な検索条件を自動で推定できれば、サーバルーム内で必要な作業は、本番データの取得・検索条件の推定・SQLの実行・実行計画の取得となります。サーバルーム内でのデータの目視確認を伴う作業がなくなることで、開発者・運用者双方にとって作業負荷の軽減が期待できます。

……という論文があれば、やっぱり是非読みたいんだけど、誰か知りませんか。あるいは、だれかこのネタでひとつ論文を書きませんか、マジで。