こんにちは。インサイトテクノロジーの松尾です！
7月も中盤に入り、札幌でも日中は25度を超える日が続くようになってきました。ただ、東京と異なるところとしては、札幌の夜は夏でも比較的涼しいこと。たまに夜も暑い日があるのですが、基本は夜は涼しいため、真夏でも窓を開けて寝ると寒い日もあるくらいです。
ところで、YugabyteDBについてご存じでしょうか？
YugabyteDBはPostgreSQL互換のクラウドネイティブ分散SQLデータベースです。
PostgreSQL互換ということでさくっと使い始められるような気もするものの、本当にそうなのか、普通のSQLが実行できるのか、不安に感じる方もいると思います。以下を見ると、大きな制限はなさそうですね。
PostgreSQL互換ということで、今回のブログではInsight Database Testingで評価可能かを確認してみたいと思います。
YugabyteDBはYugabyteDB Managedを使用
YugabyteDBの用意は、無料で試すことのできる YugabyteDB Managed を使用しました。サインアップして無料のクラスターを簡単に用意できます。
アカウント作成後は、ステップに従って必要情報を入力するのみで、簡単に接続可能なデータベースを用意できました。
クラスタの作成先はAWSかGCPを選択可能です。
作成後は、作成時に入力した情報で接続可能です。dbeaverからも簡単に接続できます。
Oracle Databaseからの移行を想定して試す
ところで、YugabyteDBでInsight Database Testingの動作確認を行うにあたり、まずはテーブルやデータなどのスキーマをYugabyteDBに用意してあげる必要があります。今回は、移行をサポートするツールであるYugabyteDB Voyagerを使用して、Oracleのスキーマとデータを移行してみます。
YugabyteDB Voyagerは、YugabyteDBへの移行を強力にサポートするツールという触れ込みで、現バージョンでは、Oracle、MySQL、PostgreSQLからの移行をサポートしています。
ツールのインストールを行った後は以下の流れで移行を行います。
- ソースから、スキーマをエクスポートと確認
- ソースから、データをエクスポート
- ターゲットへ、スキーマをインポート
- ターゲットへ、データをインポート
インストールについてはgithubからcloneしてインストールコマンドを実行するだけなのですが、Dockerfileでも用意しておいていただけると、もっと手間が省けてありがたいですね。なお、インストールの途中でOra2Pg利用の確認が求められました。Oracleからの移行については、内部的にはOra2Pgを使っているということでしょうね。
以下のような感じで実行することができました。
ソースから、スキーマをエクスポートする実行例
$ yb-voyager export schema --export-dir ~/ora2yugabytedb/oracle/ --source-db-type oracle --source-db-host XX.XX.XX.XX --source-db-name pdb1 --source-db-schema scott --source-db-user scott --source-db-password ********
スキーマの確認例
$ yb-voyager analyze-schema --export-dir ~/ora2yugabytedb/oracle/ --source-db-type oracle --source-db-host XX.XX.XX.XX --source-db-name pdb1 --source-db-schema scott --source-db-user scott --source-db-password ******** --output-format txt
$ cat oracle/reports/report.txt
+---------------------------+
| Database Migration Report |
+---------------------------+
Database Name pdb1
Schema Name SCOTT
DB Version Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Objects:
Object: TABLE
Total Count: 10
Valid Count: 10
Invalid Count: 0
Object Names: t_char, test, test1, testtable, bonus, dept, emp, float_test, salgrade, testtable2
スキーマのインポート実行例
$ yb-voyager import schema --export-dir ~/ora2yugabytedb/oracle/ --target-db-host xxx.xxx.xxx.xxx --target-db-name yugabyte --target-db-schema public --target-db-user scott --target-db-password ********
データのインポート実行例
$ yb-voyager import data --export-dir ~/ora2yugabytedb/oracle/ --target-db-host xxx.xxx.xxx.xxx --target-db-name yugabyte --target-db-schema public --target-db-user scott --target-db-password ********
DBeaverで確認してみると、きちんとデータが入っていました。
今回、小さなデータセットの移行を試してみたのみですが、特にエラーも出ずに移行できました。
なお、気づいたところとしては、Ora2Pgの仕様ではありますが、number型は精度の設定状況により、numeric型でなくfloat型へ変換されるようです(オプション指定でnumeric型にすることも可能)。これは、OracleからPostgreSQLへの移行の一般的な話ですが、numeric型のパフォーマンスがよくないため、正確に固定小数点を扱いたい場合を除いては、doubleやfloatへの移行が一般的には推奨されるようです。SCTを使ったときはnumeric型に変換されていたので、このora2pgとの違いもいずれまとめてみたいところです。
- 参考：https://ora2pg.darold.net/documentation.html#Column-type-control
- 参考：https://aws.amazon.com/jp/blogs/database/convert-the-number-data-type-from-oracle-to-postgresql-part-1/
Insight Database Testingで確認
では続いてInsight Database Testingで確認してみます。今回、OracleもYugabyteDBも、特にパフォーマンスを意識して環境を用意しているわけではないため、SQL実行時のパフォーマンス以外での挙動を評価できることを確認します。
実行したSQLは以下の3つ
select empno, ename, job, mgr, to_char(hiredate, 'YYYY-MM-DD') as hiredate, to_char(sal, '99999.99') as sal from emp;
select empno, ename, job, mgr, to_char(hiredate, 'YYYY-MM-DD') as hiredate, to_char(sal, '99999.99') as sal from emp order by empno;
select empno, ename, d.deptno, d.dname, job, mgr, to_char(hiredate, 'YYYY-MM-DD') as hiredate, to_char(sal, '99999.99') as sal from emp e left outer join dept d on e.deptno = d.deptno order by deptno, empno;
このSQLをOracleで実行すると、Insight Database Testingへ実行されたSQLが蓄積されます。
なお、Insight Database TestingからYugabyteDBへは、PostgreSQLとして問題なく接続できました。
アセスメント実行時には、ヘッダーの大文字/小文字を無視、実行時間比較時の1秒以内の差は無視、SELECT結果は順序も含めて比較(相違がある場合は順序を無視すれば正しいかも確認)などの比較オプションを設定しました。
アセスメントを実行すると、以下のように、ORDER BYがついているものは問題なく、ORDER BYがついてないものはエラーとなりました。ORDER BYがない場合は順序が不定なので当然でしょうか。なお、順序を無視すると問題ないことも確認できました。
このように、アプリケーション側から見ると、PostgreSQLとして接続しSQLを実行、簡単なSQLにおいてはOracleとの比較も問題ないことが確認できました。
おわりに
普通のPostgreSQLでなくYugabyteDBへ移行するモチベーションとしては、分散SQLとしての特徴を享受したいケースが多いと思います。一方、対障害性やスケール性能などは、Insight Database Testingでは評価しづらいため、これらは、別途確認いただく感じになるとは思います。
本ブログでは、YugabyteDBへの移行アセスメントにあたって、YugabyteDB Voyagerを使って環境を用意し、Oracleで実行したSQLをInsight Database Testingで収集し、YugabyteDBに対して評価実行し、移行アセスメントに利用可能であることを確認しました。対障害性やスケール性能が満足いくものでも、アプリケーションが期待通りに動作するかは、SQLが期待通りの挙動を示すかの確認が必須であり、Insight Database Testingをその確認に利用可能です。
Insight Database Testing をまだご利用いただいていない方で実際に試されたい場合は、製品の説明やデモ、トライアルなどについて
Insight Database Testingに関するお問い合わせ よりお問い合わせいただければと思います。
MySQL互換の分散SQLデータベース TiDB も同様に気になっているので、近いうちに試してみたいと思います。
次回もどうぞお楽しみに！
