s u m m i t · 2020-04-11 · (日付/時刻の演算②の1 date型+ or...

S U M M I TTokyo 2019

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T

プロジェクトの実例に学ぶデータベースマイグレーションの課題と解決

関口裕士ビッグデータコンサルタントプロフェッショナルサービス本部アマゾンウェブサービスジャパン株式会社

B 3 - 2


当セッションの目的Oracle DatabaseからAurora PostgreSQLへの移行案件を支援して気づいた代表的な考慮事項の紹介と解決方を共有させていただき、スムーズなデータベース移行の参考としていただきたいと考えています

Oracle DatabaseからAurora PostgreSQLへ移行予定、検討されているDBA、開発者

対象視聴者

対象サービス

Aurora compatible with PostgreSQL (9.6系) 10系


関口裕士（Hiroshi Sekiguchi）Bigdata Consultant, AWS Professional Services

略歴• Captainシステム開発（汎用機)、外資系ベンダーにてNoSQLデータ

ベース（今風に言えば）を担当• 30年のフリーランスを経て、2018年5月より現職• db tech showcase等、DB/SQLチューニングセッション多数• 直近10年、性能関連コンサル多数の性能問題の治療に従事

• (日本人現役) Oracle ACE の1人

得意分野• SQLのパフォーマンス問題の治療• DBのパフォーマンス問題の治療


アジェンダ

• はじめに

• データベースエンジン由来の代表的考慮事項と対応策

• Aurora PostgreSQL由来の代表的考慮事項と対応策

• まとめ


用途に応じたAWSのデータベースサービス

Relational Key-value Document In-memory Graph Time-series Ledger

DynamoDB NeptuneAmazon RDS

Aurora CommercialCommunity

Timestream QLDBElastiCacheDocumentDB


Amazon Aurora

1/10のコストで商用データベース相当のパーフォーマンスと可用性を持つ、クラウド向けに設計されたMySQL/PostgreSQL互換のRDBMS

パフォーマンスとスケーラビリティ

可用性と堅牢性

高いセキュリティマネージドサービス

MySQLの5倍のスループットPostreSQLの3倍のスループットリードレプリカは最大15ノード

までスケールアウト可能

堅牢性, セルフヒーリングストレージ ; 3AZ間で6つのデータのコピー,

S3への継続的バックアップ

ネットワークの分離, 格納データ/伝送データ

の暗号化

H/Wプロビジョニング、パッチ、セットアップ、設定、

またはバックアップ不要


AWS SCT (Schema Conversion Tool)

• データウェアハウスをモダナイズ

Oracle, SQL Server, Netezza, Greenplum, Vertica,Teradata を Amazon Redshift へ変換する

モダナイズ

Amazon Aurora

Amazon Redshift

• データベースをモダナイズ

Oracle, SQL Server, Db2 LUW を

PostgreSQL, MySQL, Amazon Auroraへ

変換する

MySQL

PostgreSQL


Oracle Database 11g/12cTo Amazon Aurora

with PostgreSQL Compatibility (9.6.x)

移行のためのベストプラクティスを紹介

スムーズな移行にお役だてください。

Migration Playbook

https://aws.amazon.com/jp/dms/resources/

AWS Database Migration Service のリソース

移行プレイブックとステップバイステップガイド

https://aws.amazon.com/jp/dms/resources/


予備検討やPoC机上の検討、PoCを通してDBマイグレーションが妥当かを検討する

設計移行方式の設計や移行後の環境の設計を行う

変換SQLの抽出、書き換えを行い、単体テスト、結合テスト、総合性能試験を実施する

移行移行テストを実施の上、データの移行と切り替え作業を行う

運用移行終了後のデータベースの運用

最適化キャパシティの見直し、コスト最適化など運用改善の実施

Database Migrationプロセスと本セッション内容の位置付け

ディスカバリー

設計変換移行運用最適化

• スキーマ、SQL移行の難易度を調査(AWS SCT)

• スキーマの移行(AWS SCT)

• SQL、プロシージャーの移行(AWS SCT)

• データの移行(AWS SCT)

フェーズ毎に適用可能なAWS SCTの機能


データベースエンジン由来の代表的考慮事項

• NULLと空文字

• 一時表

• 日付/時刻

• パーティション



NULLと空文字https://docs.oracle.com/cd/E82638_01/sqlrf/Nulls.html

’’ (空文字) とは、長さ 0 の文字列を指します。文字列であるため、NULLとは異なります。

空文字の扱い ‘’

Oracle Database NULLとして扱う

PostgreSQL 長さ 0 バイトの空文字として扱う

https://docs.oracle.com/cd/E82638_01/sqlrf/Nulls.html

S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.


SQL> set null [null]SQL> update foo set bar = ‘’ where id = 1; -- Oracle Database

ID BAR---------- ----------

1 [null]

mydb=> ¥pset null ‘[null]’mydb=> update foo set bar = ‘’ where id = 1; -- PostgreSQL

id | bar----+--------

1 |

NULLと空文字の扱いの違い



SQL> set null [null]SQL> update foo set bar = ‘’ where id = 1; -- Oracle Database

ID BAR---------- ----------

1 [null]

mydb=> ¥pset null ‘[null]’mydb=> update foo set bar = NULL where id = 1; -- PostgreSQL

id | bar----+--------

1 | [null]

NULLと空文字の扱いの違いOracle Databaseで利用されている空文字(‘’)は、NULLへ置き換える



-- Oracle Database

SQL> SELECT ‘test’ || ‘1’ FROM dual;

‘TEST-----test1

SQL> SELECT ‘test’ || ‘’ FROM dual;

‘TES----test

SQL> SELECT ‘test’ || NULL FROM dual;

‘TES----test

文字列連結演算子(||)でのNULL連結時の挙動の違い（ ‘’ 空文字を NULLに置き換えただけで移行してしまうと… )

-- Aurora PostgreSQLmydb=> ¥pset null ‘[null]’mydb=> SELECT ‘test’ || ‘1’;

concat_ws-----------test1

mydb=> SELECT ‘test’ || NULL;

?column?-----------[null]

mydb=> SELECT ‘test’ || NULL;

?column?-----------[null]



-- Oracle Database

SQL> SELECT ‘test’ || ‘1’ FROM dual;

‘TEST-----test1

SQL> SELECT ‘test’ || ‘’ FROM dual;

‘TES----test

SQL> SELECT ‘test’ || NULL FROM dual;

‘TES----test

文字列連結演算子(||)でのNULL連結時の挙動の違いへの対処方法手動で書き換えるか、AWS SCTを利用しCONCAT_WS()に書き換える

-- Aurora PostgreSQLmydb=> ¥pset null ‘[null]’mydb=> SELECT CONCAT_WS(‘’, ‘test’, ‘1’);

concat_ws-----------test1

mydb=> SELECT CONCAT_WS('', 'test’, NULL);

concat_ws-----------test

mydb=> SELECT CONCAT_WS('', 'test', NULL);

concat_ws-----------test



一時表の挙動の差異PostgresSQLではトランザクションの終了または、セッションの終了時点で一時表定義も自動削除される

データが切り捨てられるタイミング表の削除

トランザクションセッション

Oracle Database

○ ○DROP TABLE文(自動削除されない*1)

PostgreSQL ○ ○トランザクションまたは、セッションの終了で自動削除

*1) Oracle Database 18cでは自動削除するタイプの一時表がサポートされた

↓CREATE TEMP TABLE IF NOT EXISTS文を利用して対処



日付/時刻（データ型の変換)

Oracle DatabaseのDATE型は、時分秒まで保持してるため、PostgreSQLへ移行する場合、TIMESTAMP型へ移行するのが一般的です

Oracle Database PostgreSQL

DATE型年月日時分秒年月日

TIMESTAMP型年月日時分秒.少数部年月日時分秒

年月日時分秒.少数部



日付/時刻（データ型の変換)

AWS SCTでは以下の変換（デフォルト）を行うことが可能です


DATE型 DATE型TIMESTAMP型

(タイムゾーンなし）

TIMESTAMP型 TIMESTAMP型 TIMESTAMP型



日付/時刻の演算①

Oracle DatabaseのDATE型からPostgreSQLのTIMESTAMP型への移行時AWS SCTでは以下の変換を行うことが可能です

演算パターン (データ型演算子データ型 => 結果のデータ型） AWS SCTによる変換Oracle Database PostgreSQL

1DATE型 - DATE型 =>

NUMBER型

(EXTRACT (EPOCH FROM TIMESTAMP型– TIMESTAMP型) / 86400)::NUMERIC

=> NUMERIC型○

2(DATE型 – DATE型)

+ 数値リテラル=> NUMBER型

(EXTRACT (EPOCH FROM TIMESTAMP型– TIMESTAMP型) / 86400)::NUMERIC

+ 数値リテラル => NUMERIC型○



-- Oracle Database

SQL> desc exampleName Type------------ ------------DCOL DATETCOL TIMESTAMP(6)

select dcol - dcol

from hoge.example;

日付/時刻の演算(日付/時刻の演算①の1 DATE型-DATE型の変換例）

-- Aurora PostgreSQL

mydb=> ¥d hoge.exampleTable "hoge.example”

Column | Type--------+-------------------------------dcol | timestamp(0) without time zone tcol | timestamp(6) without time zone

SELECT(EXTRACT (EPOCH FROM dcol - dcol) / 86400

)::NUMERICFROM hoge.example;



日付/時刻の演算②

Oracle DatabaseのDATE型からPostgreSQLのTIMESTAMP型への移行時AWS SCTでは以下の変換を行うことが可能です

演算パターン (データ型演算子データ型 => 結果のデータ型）AWS SCTによる変換


1DATE型 + or – 数値リテラル

=> DATE型TIMESTAMP型 + or – 期間リテラル

=> TIMESTAMP型○

2DATE型 + or – 期間リテラル


=> TIMESTAMP型○



-- Oracle Database


select dcol+ 1

from hoge.example;

日付/時刻の演算(日付/時刻の演算②の1 DATE型 + or – 数値リテラルエラーの例）

PostgreSQLでは、TIMESTAMP型に対して数値リテラルを加減算は行えません




mydb=> SELECT dcol + 1 FROM hoge.example;

ERROR: operator does not exist: timestamp without time zone + integerLINE 1: SELECT dcol + 1 FROM hoge.example;

^



-- Oracle Database


select dcol+ 1

from hoge.example;

日付/時刻の演算(日付/時刻の演算②の1 DATE型 + or – 数値リテラルの変換例）前述のエラーを回避し、演算結果をTIMESTAMP型で得るには、数値リテラルを期間リテラルに書き換える必要があります




SELECTdcol+ (1::NUMERIC || ' days')::INTERVAL

FROM hoge.example;



日付/時刻の演算③

Oracle DatabaseのTIMESTAMP型からPostgreSQLのTIMESTAMP型への移行時

演算パターン (データ型演算子データ型 => 結果のデータ型）参考


1TIMESTAMP型 – TIMESTAMP型

=> INTERVAL DAY TO SECOND型TIMESTAMP型 – TIMESTAMP型

=> INTERVAL型手動変換/SCT

2(TIMESTAMP型 – TIMESTAMP型)

+ 期間リテラル=> INTERVAL DAY TO SECOND型

(TIMESTAMP型 – TIMESTAMP型) + 期間リテラル

=> INTERVAL型手動変換/SCT

TO_TIMESTAMP()を利用している場合は手動変換必要



-- Oracle Database


select (tcol - tcol) + interval '1' day

from hoge.example;

日付/時刻の演算(日付/時刻の演算③の2 (TIMESTAMP型– TIMESTAMP型) – 期間リテラルの例）

PostgreSQLへ向けに変換する場合、期間リテラルの構文に多少違いのある点に注意してください



Column | Type--------+-------------------------------dcol | timestamp(0) without time zonetcol | timestamp(6) without time zone

SELECT(tcol - tcol) + '1 day'::INTERVAL

FROM hoge.example;



日付/時刻の演算④

Oracle DatabaseのTIMESTAMP型からPostgreSQLのTIMESTAMP型への移行時

演算パターン (データ型演算子データ型 => 結果のデータ型）参考


1TIMESTAMP型 + or – 数値リテラル


=> TIMESTAMP型手動変換/SCT

2TIMESTAMP型 + or – 期間リテラル

=> TIMESTAMP型TIMESTAMP型 + or – 期間リテラル

=> TIMESTAMP型手動変換/SCT

TO_TIMESTAMP()を利用している場合は手動変換必要



-- Oracle Database


select tcol+ 1

from hoge.example;

日付/時刻の演算(日付/時刻の演算④の1 TIMESTAMP型 + or – 数値リテラルエラーの例）

PostgreSQLでは、TIMESTAMP型に対して数値リテラルを加減算は行えません




mydb=> select tcol + 1 from hoge.example;ERROR: operator does not exist: timestamp without time zone + integerLINE 1: select tcol + 1 from hoge.hoge;

^HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.



-- Oracle Database


select tcol+ 1

from hoge.example;

日付/時刻の演算(日付/時刻の演算④の1 TIMESTAMP型 + or – 数値リテラルの変換例）前述のエラーを回避し、演算結果をTIMESTAMP型で得るには、数値リテラルを期間リテラルに書き換える必要があります




SELECTtcol+ (1::NUMERIC || ' days')::INTERVAL

FROM hoge.example;



パーティション（パーティションタイプ)HASHパーティションからの移行先をどのタイプのパーティションにするか検討する必要あります。(以下に記載していないパーティションについても同様）

HASHパーティションの主な目的は、I/O分散とパーティション間のデータ量均一化であるため、他のパーティションタイプに移行する場合には、同様の観点での検討が必要となります。

パーティションタイプ Oracle Database PostgreSQL (10.x互換) AWS SCTによる変換

RANGE ○ ○（宣言的パーティション） ○

LIST ○ ○（宣言的パーティション） ○

HASH ○ N/A N/A

※PostgreSQL 10互換のAuroraは、昨年末より東京リージョンでも利用可能となっております。



パーティションパーティション数とハードパースの関係

できる限り100以下にすることが推奨されています。理由はパーティション数の増加に伴いパース時間も伸びる傾向にあるためです。

（マニュアル）テーブルのパーティショニングhttps://www.postgresql.jp/document/10/html/ddl-partitioning.html

Oracle Databaseのコンポジットパーティション移行する場合、200、300という数のパーティションになってしまう場合もあります。OLTP系ショートクエリー等、性能要件の厳しいワークロードが想定される場合には注意が必要です。

パーティション数がSQL文の

パース時間に影響する

https://www.postgresql.jp/document/10/html/ddl-partitioning.html



パーティション親表のロックPostgreSQL宣言的パーティションでパーティションの削除(DROP)を行う場合、親表は排他ロック（ACCESS EXCLUSIVE）されます。このタイプのロックはすべてのアクセスをブロックするため、親表経由のアクセスは待機させられることになります。

（マニュアル）テーブルのパーティショニングhttps://www.postgresql.jp/document/10/html/ddl-partitioning.html

性能要件の厳しいシステムでは、削除と同時にDMLが実行される可能性が高い時間帯の実行を避ける等の対応が必要になる可能性があります。

①Partition 3を削除!

②親表はAccess Exclusive

ロックされる

https://www.postgresql.jp/document/10/html/ddl-partitioning.html


Aurora PostgreSQL由来の代表的考慮事項

インスタンスモニタリングとSQLチューニング

いわゆるTemp落ちと一時領域


Aurora PostgreSQL由来の代表的考慮事項とSQLチューニング

wait_eventの説明https://www.postgresql.jp/document/10/html/monitoring-stats.html#WAIT-EVENT-TABLE

pg_stat_activityビューhttps://www.postgresql.jp/document/10/html/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW

pg_stat_statements ビューhttps://www.postgresql.jp/document/10/html/pgstatstatements.html

https://www.postgresql.jp/document/10/html/monitoring-stats.html#WAIT-EVENT-TABLE

https://www.postgresql.jp/document/10/html/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW

https://www.postgresql.jp/document/10/html/pgstatstatements.html


Aurora PostgreSQL由来の代表的考慮事項インスタンスモニタリングとSQLチューニング


2

1

3


2

1

3

4



Amazon Aurora Amazon Aurora

参考) No Space Left on Device (デバイスに空き容量がない) エラーへの対応https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Aurora.NoSpaceLeft

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Aurora.NoSpaceLeft


まとめ

データベースエンジン由来の代表的考慮事項一時表、NULLと空文字、日付/時刻の演算、パーティション

Aurora PostgreSQL由来の代表的考慮事項インスタンスモニタリングとSQLチューニング、

本日ご紹介した内容は全体の一部でございますが、皆様の助けになれば幸いでございます


（参考）AWS SCT利用時のTips

• 利用している全データ型を含む表を１つ定義し変換することで、デフォルトのデータ型の変換マッピングの全容を早期に確認する

Oracle DatabaseからAurora PostgreSQLの変換例


Thank you!


Hiroshi [email protected]

s u m m i t · 2020-04-11 · (日付/時刻の演算②の1 date型+ or...

Documents