Insight Technology

2022.07.21

YugabyteDBへの移行をInsight Database Testingで評価できるか試してみる

このエントリーをはてなブックマークに追加

こんにちは。インサイトテクノロジーの松尾です!

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との違いもいずれまとめてみたいところです。

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 も同様に気になっているので、近いうちに試してみたいと思います。

次回もどうぞお楽しみに!

TOP
ページトップへ