【レポート】プロジェクトの実例に学ぶデータベースマイグレーションの課題と解決 #AWSSummit
こんにちは、崔です。
AWS Summit Tokyo 2019 3日目のB3-02のセッションである「プロジェクトの実例に学ぶデータベースマイグレーションの課題と解決」のレポートをお届けします。
オンプレミスのデータベースからクラウド上のデータベースへの移行においては、お客様の状況や要件に応じて様々な課題が生まれます。昨年から複数の移行プロジェクト(Aurora PostgreSQLへの移行プロジェクト）を支援して気づいた代表的な移行に伴う課題やその傾向及び、その解決について、オンプレミスとクラウド由来の差異、データベースエンジン由来の差異、チューニング方法などの差異などいくつかの視点からご紹介していきます。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社
プロフェッショナルサービス本部
コンサルタント 関口 裕士 様
当セッションの目的
Oracle DatabaseからAurora PostgreSQLへの移行案件を支援して気づいた代表的な考慮事項の紹介と解決方法を共有
はじめに
Amazon Aurora
1/10のコストで商用DB相当のパフォーマンスと可用性を持つ、クラウド向けに設計されたMySQL/PostgreSQL互換のRDBMS
AWS SCT
- ソースDBのスキーマをターゲットに変換
- ソースDBのアプリケーション、SQLを変換
- データ移行
- CSV形式の移行
- DMSとの連動
- サマリーレポート マイグレーションの難易度を判断
Database Migrationプロセスと本セッションの位置づけ
- ディスカバリ
- 予備検討やPoC
- スキーマ、SQL移行の難易度を調査
- 設計
- 変換
- スキーマの移行
- SQL、プロシージャの移行
- 移行
- データの移行
- 運用
- 最適化
データベースエンジン由来の代表的考慮事項と対応策
- NULLと空文字
- 一時表
- 日付／時刻
- パーティション
NULLと空文字
- Oracle：空文字をNULLと扱う
- PostgreSQL；空文字を長さ０バイトの空文字として扱う
- Oracleで条件文でNULLとして空文字を利用している場合は、NULLへの置き換えが必須
- 文字列連結演算子でのNULL連結時の挙動の違い
- （この場合は、空文字をNULLに置き換えて移行してしまうと不一致）
- CONCAT＿WS関数を使う
一時表
PostgreSQLではトランザクションの終了、または、セッションの終了で一時表も自動削除される
- Oracleの場合は、drop table文実行時に削除
- PostgreSQLの場合は、トランザクション、セッション終了時に自動削除される
- create temp table if not exists文を利用して対処
日付／時刻
- Oracle のDATE型は、年月日時分秒まで保持している
- Postgreは年月日までしかない
- TIMESTAMP型の利用で時分秒まで保持できる
- AWS SCTではデフォルトでDATE型からTIMESTAMP型に変換される
演算パターンその１
Oracle:(DATE型 - DATA型）=> NUMBER型 のような演算の場合、
PostgreSQL:(EXTRACE(EPOCH FROM TIMESTAMP型 - TIMESTAMP型) / 86400::NUMERIC) => NUMERIC型 と変換
Oracle:(DATE型 - DATA型）+ 数値リテラル => NUMBER型 のような演算の場合、
PostgreSQL:(EXTRACE(EPOCH FROM TIMESTAMP型 - TIMESTAMP型) / 86400::NUMERIC) + 数値リテラル => NUMERIC型 と変換
演算パターンその２
Oracle:DATE型 +/- 数値リテラル => DATA型 のような演算の場合、
PostgreSQL:TIMESTAMP型 +/- 期間リテラル => TIMESTAMP型 と変換
Oracle:DATE型 +/- 期間リテラル => DATA型 のような演算の場合、
PostgreSQL:TIMESTAMP型 +/- 期間リテラル => TIMESTAMP型 と変換
演算パターンその３
Oracle:TIMESTAMP型 - TIMESTAMP型 => INTERVAL DAY TO SECOND型 のような演算の場合、
PostgreSQL:TIMESTAMP型 - TIMESTAMP型 => INTERVAL型 と変換
Oracle:(TIMESTAMP型 - TIMESTAMP型) + 期間リテラル => INTERVAL DAY TO SECOND型 のような演算の場合、
PostgreSQL:(TIMESTAMP型 - TIMESTAMP型) + 期間リテラル => INTERVAL型 と変換
演算パターンその４
Oracle:TIMESTAMP型 +/- 数値リテラル => DATE型 のような演算の場合、
PostgreSQL:TIMESTAMP型 +/- 期間リテラル => TIMESTAMP型 と変換
Oracle:TIMESTAMP型 +/- 期間リテラル => DATE型 のような演算の場合、
PostgreSQL:TIMESTAMP型 +/- 期間リテラル => TIMESTAMP型 と変換
パーティション
- HASHパーティションからの移行先をどのタイプのパーティションに移行するか検討する必要がある。
- PostgreSQL10には、レンジパーティションとリストパーティションしかサポートされていない
- HASHパーティションの主な目的はI/O分散とパーティション間のデータ量均一化であるため、他のパーティションに移行する場合は、同様の観点での検討が必要
- パーティション数とハードパースの関係
- 出来る限りパーティション数100以下にすることが推奨されている
- パーティション数の増加に伴いパース時間も伸びる傾向にあるため
- Oracleのコンポジットパーティションの場合、２００、３００となっているケースもあるため、注意
- 親表のロック
- パーティションの削除を行う場合は、親表は排他ロック（ACCESS EXCLUSIVE）される
- 全てのアクセスをブロックするため、DMLが待たされる
- 性能要件の厳しいシステムでは、パーティションの削除と同時にDMLが実行される可能性が高い時間帯に、削除の実行を避ける必要あり
Aurora PostgreSQL由来の代表的考慮事項と対応策
インスタンスモニタリングとSQLチューニング
- 基本はPostgreSQL由来の統計情報ビュー
- pg_stat_activityビュー
- v$sessionに類似
- wait_event列の待機イベントを確認することでSQL単位の特徴をモニタリング
- pg_stat_statementsビュー
- v$sqlstatsに類似している情報を保持
- EXTENSIONとして追加する必要あり。少々オーバーヘッドはあるが、デメリットを上回るメリットあり
- 有効化した上でPoCや性能試験を行うことをおすすめ
Performance Insights
- 待機イベントによるインスタンスモニタリング
- Top N SQLによるSQLワークロードモニタリング
- 7日間のパフォーマンス履歴の保存
- 100万リクエスト／月までの無料枠と必要に応じ2年間のパフォーマンス履歴保存
-
モニタリングしたSQLはコピーボタンでコピー可能
- psql等のクライアントツールからexplain analyze文を実行
いわゆるTemp落ちと一時領域
- 作業用メモリ内でハッシュ結合やソートが行える場合には一時領域を利用しない
- 作業用メモリ内でハッシュ結合やソートが行えないデータ量になると一時領域が利用される
- 一時領域へのI/O増加、いわゆるTemp落ちの発生の場合、CloudWatchを使い一時領域の空きを確認
- 空きローカルストレージメトリックを監視
一時領域不足への対策として
- インスタンスタイプの大きさにより、一時領域として利用できるローカルストレージのサイズが異なる
- 一時領域の利用を減らすようワークロードを調整／SQLチューニングなど
- 一時領域が不足する場合には、より大きなインスタンスタイプに変更
- 一時的に不足が懸念される作業を行う場合には、一時的に大きなインスタンスタイプへ
まとめ
- データベースエンジン由来の代表的考慮事項と対応策
- 一時表
- NULLと空文字
- 日付／時刻の演算
- パーティション
- Aurora PostgreSQL由来の代表的考慮事項と対応策
- インスタンスモニタリングとSQLチューニング
- いわゆるTemp落ちと一時領域
おまけ（SCTのTips）
利用している全データ型を含む表を一つ定義し変換することで、 デフォルトのデータ型の変換マッピングの全容を早期に確認する
感想
OracleからAmazon Aurora PostgreSQLに移行する際に気をつけるポイントがノウハウとして公開されました。こういったつまずきポイントは事前にしっかり検証しておきたいですね！
