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

リンク

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

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

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

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

Agenda

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

3.技術的なハードル

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

3.1.関数の有無
3.2.関数(同機能)の挙動差異
3.3.SQL構文の有無      ←前回ここまで
3.4.データ型の差異      ←今回ここから
3.5.ソート順の差異
3.6.性能関連の機能の有無

3.4.データ型の差異

「MySQL Oracle データ型」あたりでググると以下のようなページが出てきます。
データ型のマッピング自体はコレを見ると良いでしょう。

データ型というよりも、文字コードの設定で苦労した印象があります。
MySQLは文字コードの設定の他にCollation(照合順序)の設定があり、開発環境(@開発拠点)と本番環境(@お客さんのところ)で設定値が異なっていたため、軽い騒ぎが起きました。

併せて、寿司ビール問題なんかにもハマりかけたので参考にどうぞw

3.5.ソート順の差異

OracleとMySQLではソート順にも差の出る部分があります。
NULLを含む列のソートです。
“ORDER BY <COLUMN_NAME> ASC”でデータをソートした場合、OracleではNULLが最後にMySQLでは先頭に表示されます。
プロジェクトの方針ということで、”ORDER BY IFNULL(<COLUMN_NAME>, ‘1’), <COLUMN_NAME> ASC”などとして対応しました。
が、ホンネを言うと、「DBのエンジンが違うものになるのだから、コレ(Oracle/MySQLのソート結果の差異)くらい先にネゴってお客さんからAgreeもらっといてよ」というところです。
NULL関係はソート順、関数の挙動などで度々悩まされることがあるので、実機による検証を強くオススメします。
上記のIFNULL関数での対応はプロジェクト方針として採用されたコーディング技法でしたが、ググったところこんな記事も出てきましたので、ご参考まで。(※実機検証してくださいねw)

3.6.性能関連の機能の有無

ここでは性能関連で、OracleにあってMySQLに無いために対応に苦労した機能について記述します。

HASH JOINが無い

性能関連で一番苦労したのがコレですね。
OracleにはHASH JOINがあるので、大量データのテーブル同士を結合しても割と難なくこなせるのですが、MySQLにはこの機能が無いために、大量データのテーブル同士を結合すると動かなくなります。
主な対応としては、SQLをあの手この手で組み替えて結合前にデータを絞り込む事で、どうにか動くようになりました。

述語のプッシュが無い

もの凄くざっくり話すと、OracleはWHERE句の絞り込み条件で他のテーブルにも適用できるものがあると、オプティマイザが良い感じに使いまわしてくれます。(詳細についてはコチラでどうぞ。)
この機能のお陰で、OracleのSQLはデータの絞り込み条件をシンプルに記述することができました。
MySQLではこの機能が無いために、各テーブル用にデータの絞り込み条件を一々書く必要があります。
お陰でSQLが異様に長くなって読みにくいったらありゃしない。。。(;´Д`)

私見ですが、関数や機能の有無で四苦八苦するということは、元々のデータ設計およびテーブル設計がよろしくないのが原因です。
汎用機からの焼き直しシステムであれば、RDBMSの特性を活かしたデータ設計で再設計をすること。
データ設計の際に、きちんと正規化すること。
シンプルなデータ取得ができるようにテーブル設計をすること。
SELECTする際に一々関数で計算する必要があるならば、計算結果を別カラムで登録しておくこと。
等々、設計段階でちょっとした気を利かせておけば、性能劣化などはそうそう起こらないと考えています。

今回はここまで。