OracleからAurora(MySQL)への移行(その4)

プロジェクトレポート

2018年4月いっぱいで抜けることになったプロジェクトについて、DB技術者のオッサンが実際に現場で思ったことや感じたことを書き残すプロジェクトレポート的な社員ブログです。

リンク

OracleからAurora(MySQL)への移行(その1)

OracleからAurora(MySQL)への移行(その2)

OracleからAurora(MySQL)への移行(その3)

Agenda

  1. プロジェクト概要
  2. クラウド化のメリット/デメリット
  3. 技術的なハードル          ←イマココ
  4. サマリ

3.技術的なハードル

OracleからAurora(MySQL)へ移行する際に技術的に苦労した点を書きたいと思います。
大きく、以下の点から記述しようと思います。

3.1.関数の有無
3.2.関数(同機能)の挙動差異
3.3.SQL構文の有無
3.4.データ型の差異
3.5.ソート順の差異
3.6.性能関連の機能の有無

3.1.関数の有無

厳密に言うと関数ではないものも含めてしまいますが、OracleにあってMySQLに無い関数というのが結構あります。
例えば、ROWIDのような疑似列やROW_NUMBERのような分析関数であったり。
今回のプロジェクトでは、基本的には同じような機能を探して置き換えたのですが、上記のような関数については強引なまでのSQL書き換えを行いました。
お蔭で元々長いSQLが更に数百行のオーダーで長くなることがしばしばありました。
関数の書き換えに関しては結構サンプルが落ちているので、まずはググってみることをオススメします。

3.2.関数(同機能)の挙動差異

同じ名前の関数があっても、使い方が少し違ったりすることがあります。
この程度のことは若干のSQLの修正で済むのですが、挙動が異なることがありました。
印象深いものをあげると、CONCAT関数でNULLをくっつけた場合、OracleではなぜかNULLにならず、MySQLではNULLになることでした。
この件に関しては、MySQLの挙動が正しいと思います。
他にも挙動の異なる関数があるので、油断せずに調査および実機検証することをオススメします。

3.3.SQL構文の有無

MySQLは軽さを重視して開発されているため、複雑な構文が用意されていません。
一方で、Oracleは便利な機能が満載です。
正直、きっちりとデータへのアクセスパスを考えることができれば、余計な機能と言ってもいいほどの機能が実装されています。
SQL構文の有無という点で、今回のプロジェクトで1番苦労させられたのがWITH句でした。

ちょっとだけdisりますが、今回のプロジェクトでは、WITH句をあまりにも多用しすぎるあまり、結果的に1つのSQLで同じテーブル(しかもデータ件数が最大級のヤツ)を何重にも呼び出しており、猛烈な性能劣化を起こしていました。
便利な機能を多用しすぎてSQLがシッチャカメッチャカになって、開発者や設計者もどうやってデータが取れてるのか分かってないっていう、モノツクリ屋さんにあるまじき状態になっていました。

で、チューニングも兼ねてWITH句を解消後に、テーブルの重複呼び出しを解消するようにSQLを組み替えたりしたら、MySQL上で動かなくなっていたSQLが数分で動くようになりました。
多分、このSQLをOracle上で動かしたら、恐らく爆速です(笑)
ちょっとウデ自慢が入りましたが、この項はこんなところで。

長くなるので、今回はここまでにしようと思います。

コメント

タイトルとURLをコピーしました