異種DB移行の壁を乗り越える！③性能の壁編

こんにちは、丸山です。

前回に続き、Oracle DBからMySQLへの異種DB移行に関する事例を紹介します。
本日は、③性能の壁です。

【Oracle to MySQL】異種DB移行の壁を乗り越える！①変換の壁、②仕様の壁編

Oracle からMySQLへの変換について実際の事例の中から紹介します。

③性能の壁　<VIEWのTEMPTABLEアルゴリズム>

同じRDBMSでも、オプティマイザはそれぞれ独自に開発されているので、アルゴリズムも製品によって異なり、その違いにより性能問題が発生してしまうこともあります。その中でも、今回はTEMPTABLEアルゴリズムについて紹介したいと思います。

MySQLのビューに関するアルゴリズムは3種類ありますが、その中でTEMPTABLBEアルゴリズムが採用されるケースは注意が必要です。

では、TEMPTABLEアルゴリズムについて、もう少し詳しく説明します。
以下の例について説明していきます。

・イベントの参加者一覧(テーブルt)から、20歳以上の参加者一覧のView(ビューv)を作成
・このビューvから東京都からの参加者を抽出したい

この場合、VIEWの定義は

CREATE VIEW v_Adult (v_No,v_Name, v_Pref ) AS
SELECT v_No,Name, Pref FROM Guest WHERE Age > 19;

欲しいデータを取得するためのSELECT分は以下となります。

Select * from v_Adult where v_pref = “東京都”;

このVIEWを検索するSELECT分を実行した際に、内部でどのような処理をするのかがアルゴリズムの種類によって変わります。

例えば、MERGEアルゴリズムが採用された場合、内部ではVIEWの参照先テーブルから直接検索が実施されるのに対し、
TEMPTABLEアルゴリズムが採用された場合、内部でVIEWの実行を実施しその結果を一時保存したうえで本来のSELECT分がその一時保存されたテーブルに対して実行されます。そのため、必要のないデータが大量に読み込まれ、無駄なI/Oが大量発生した結果、性能が下がってしますのです。

もちろん、上記のSQLはTEMPTABLEアルゴリズムを説明するために用意したものなので、実際はMERGEアルゴリズムが採用され効率的な実行がされますのでご安心を。

実際に起きた一例としては、本来テーブルからは400行ほどの読み込みですむSQL分が、TEMPTABLEアルゴリズムが採用されるケースに該当したため1億行もの読み込みが発生してしまい、処理時間が長くなってしまいました。

そのため、TEMPTABLEアルゴリズムが採用されないように書き換える必要があります。しかし、書き換えは単純なものではなく、SQLを熟知した技術者がそれぞれのSQLを個別に書き換える必要がありました。その上、私たちが携わった案件ではVIEWを多用しており、TEMPTABLEアルゴリズムが採用される条件に当てはまりそうなSELECT分が多く、書き換えには多くの時間が発生してしまいます。

そのため、以下のような手順で書き換えを実施し、対応することにしました。