この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
昨年末に発表され、その後プライベートベータの状態だったBabelfishが遂にGAとなりました。
Microsoft SQL Serverをデータストアにもつアプリケーションを改修せずに、Auroraへ移行できるかもしれないということで、注目していた方は多いかもしれません。
本日はBabelfishを有効化し、SQL ServerクライアントとPostgreSQLクライアントからそれぞれアクセスし、どうやってアクセスすればよいのか、どのように見えるのかを確認してみました。
リソース作成と有効化
使い方ですが、通常どおり Aurora for PostgreSQLを作成し、Babelfish機能を有効化するだけです。
ただし、PosgreSQLバージョンは最新の13.4を選択する必要があります。
また、キャパシティータイプはプロビジョニングを選択する必要があります。
バージョンが古かったり、キャパシティタイプがサーバレスだったり、RDS for PostgreSQLの場合は、Babelfishが有効化できないので注意してください。
条件を満たしていれば、オプションが有効化出来るようになります。
また、Babelfish自体のオプションとして、データベース移行モードに「１つのデータベース」と「複数のデータベース」のどちらかを選択します。
今日のところは細かいことはおいておいてとりあえずアクセスしてしまいたいところなのですが、Babelfishを利用するうえでこの設定を含めたスキーマの構成部分は理解しておいたほうが良い部分なのでデータベース移行モードだけ少し触れます。
Babelfishを有効化したAuroraクラスターはPostgreSQLのポート5432と、TDSのポート1433どちらかもアクセス出来るようになります。
また、babelfish_dbが作成され、TDSでアクセスした際はこのデータベース内にオブジェクトが格納されます。
なので、例えばhogeというデータベースをSQL ServerクライアントからAuroraへ接続後に作成した場合でも、PostgreSQLクライアントからはbabelfish_dbでアクセスする必要があります。
Working with Babelfish for Aurora PostgreSQL - Amazon Aurora より
複数のデータベースについては後述します。
まずは１つのデータベースを選択して検証してみましょう。
クライアントからアクセス
Azure Data Studioを使ってアクセス
接続は出来ました。
スキーマを指定した上で、クエリ実行することも出来ました。
データベース、テーブル、レコードを作成しました。
ただし、オブジェクトツリーが開けませんでした。
この後の操作はコンソールから行いたいと思います。
PostgreSQLクライアントからアクセス
PostgreSQLには普段Auroraを利用する際と同じようにアクセスすれば良いです。
データベース一覧を確認してみると、babelfish_dbが存在することが確認出来ると思います。
iwasa.takahito@hoge ~ % psql -U postgres -h database-1.cluster-cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com
Password for user postgres:
psql (14.0, server 13.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------------+----------+----------+-------------+-------------+--------------------------
babelfish_db | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres +
| | | | | postgres=CTc/postgres +
| | | | | sysadmin=C*T*c*/postgres+
| | | | | master_dbo=CTc/sysadmin +
| | | | | tempdb_dbo=CTc/sysadmin +
| | | | | dbo=CTc/sysadmin
dvdrental | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
rdsadmin | rdsadmin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | rdsadmin=CTc/rdsadmin
template0 | rdsadmin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/rdsadmin +
| | | | | rdsadmin=CTc/rdsadmin
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(6 rows)
postgres=> \c babelfish_db
psql (14.0, server 13.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
You are now connected to database "babelfish_db" as user "postgres".ちなみに、dvdrentalはPostgreSQLクライアントでインポートしたサンプルなのですが、babelfish_dbの外にいるので、SQL Serverクライアントからはアクセス出来ませんでした。
babelfish_dbを指定するとクエリを実行することが出来ます。
babelfish_db=> \dn
List of schemas
Name | Owner
------------+-----------------
dbo | db_owner
master_dbo | master_db_owner
public | postgres
sys | rdsadmin
tempdb_dbo | tempdb_db_owner
(5 rows)
babelfish_db=> select * from dbo.piyo;
foo | fuga
-----+-------
1 | hoge1
2 | hoge2
3 | hoge3
(3 rows)先程SQL Serverクライアントで作成したレコードにPostgreSQLからアクセスすることが出来ました。
逆の確認も行いたいので、PostgreSQLからレコードの新規作成を行っておきます。
babelfish_db=> insert into dbo.piyo (fuga) values ('hoge4');
INSERT 0 1SQL Serverクライアントからアクセス
今回は以下を参考にさせて頂き、SQL Serverコマンドラインツールを使用してアクセスすることにしました。
iwasa.takahito@hoge bin % sqlcmd -S database-1.cluster-cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com,1433 -U postgres
Password:
1> select * from dbo.piyo;
2> go
foo fuga
----------- --------------------
1 hoge1
2 hoge2
3 hoge3
4 hoge4
(4 rows affected)PostgreSQLクライアント側から作成したデータを確認することが出来ました。
SQL Serverクライアントからアクセスする際はbabelfish_db内にいることを意識することはありません。
複数のデータベース
さて、Aurora構築時のBabelfishのオプションとして、データベース移行モードがあり、先程は「１つのデータベース」を選択しました。
今度は「複数のデータベース」を選択してみます。
複数のデータベースを選択した場合でも同様にbabelfish_dbへ格納されます。
その場合別名のDBで同一スキーマ名で重複する可能性があるので、SQL Server側のDB名とスキーマ名を組み合わせた名前でbabelfish_dbへ格納されます。
SQL Serverクライアントからアクセス
SQL Serverクライアントから、データベースを２つ作成しレコードを作成します。
iwasa.takahito@hoge bin % sqlcmd -S database-2.cluster-cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com,1433 -U postgres
Password:
1> create database hoge1;
2> create database hoge2;
3> go
1> use hoge1;
2> go
Changed database context to 'hoge1'.
1> create table piyo (foo INT NOT NULL, fuga VARCHAR(20) NULL);
2> go
1> insert into piyo values (1, 'aaa');
2> insert into piyo values (2, 'bbb');
3> insert into piyo values (3, 'ccc');
4> go
(1 rows affected)
(1 rows affected)
(1 rows affected)
1> use hoge2;
2> go
Changed database context to 'hoge2'.
1> create table piyo (foo INT NOT NULL, fuga VARCHAR(20) NULL);
2> go
1> insert into piyo values (4, 'ddd');
2> insert into piyo values (5, 'eee');
3> insert into piyo values (6, 'fff');
4> go
(1 rows affected)
(1 rows affected)
(1 rows affected)PostgreSQLクライアントからアクセス
先程作成されたオブジェクトへどのようにアクセス出来るのか確認してみたいと思います。
iwasa.takahito@hoge ~ % psql -U postgres -h database-2.cluster-cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com
Password for user postgres:
psql (14.0, server 13.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> \c babelfish_db
psql (14.0, server 13.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
You are now connected to database "babelfish_db" as user "postgres".
babelfish_db=> \dn
List of schemas
Name | Owner
------------+-----------------
hoge1_dbo | hoge1_db_owner
hoge2_dbo | hoge2_db_owner
master_dbo | master_db_owner
public | postgres
sys | rdsadmin
tempdb_dbo | tempdb_db_owner
(6 rows)ドキュメントで解説されていたとおり、SQL Server側のDB名_スキーマ名にマッピングされていますね。
babelfish_db=> select * from hoge1_dbo.piyo;
foo | fuga
-----+------
1 | aaa
2 | bbb
3 | ccc
(3 rows)
babelfish_db=> select * from hoge2_dbo.piyo;
foo | fuga
-----+------
4 | ddd
5 | eee
6 | fff
(3 rows)スキーマを指定し、それぞれの論理的には別のデータベースのレコードへアクセスすることが出来ました。
データベースが統合されてスキーマで分離し直された感じですね。 PostgreSQLクライアント側からアクセスする際は意識する必要があります。
さいごに
パフォーマンスや、バージョン互換、制限事項など気になる点はまだまだ多いですが、Auroraにどう組み込まれているのかどれくらいライトに使えそうかが伝われば嬉しいです。
単純なデータベース作成、テーブル作成、レコード作成において相互にアクセスすることが確認出来ました。
まだレガシーアプリケーションの移行いけますね！と言えるほど評価できていないので、次はMicrosoft SQL Serverを前提とする重めのワークロードをBabelfish for Aurora PostgreSQLに移行・評価してみたいと思います。
以前Kenticoという製品をAWS環境へデプロイしたのですが、ASP.NET Web Form + Microsoft SQL ServerなCMSで、ストアドも結構使われていたと記憶しています。
もしKenticoが完全に動くとすると、かなり実用的なレベルなんじゃないかなと個人的には思います。
レガシーアプリケーションがコードを大幅に書き直すことなく、Aurora と通信できるようにします。
ただ、ドキュメントには上記のような書き方がいくつもあったので多少は書き直すことも想定されてるのかなぁ、とも思っています。
5
