こんにちは。インサイトテクノロジーの松尾です！
11月になりました。もう札幌は毎日だいぶ寒いデス。
さて、先日、YugabyteDBへの移行をInsight Database Testingで評価できるか試してみる というブログで、Insight Database TestingでPostgreSQL 互換のYugabyteDBへの移行テストに使えるかを確認しました。
今回は、MySQL互換のTiDBについて同様のことができるかを確認します。
ところで、TiDBについてご存じでしょうか？
TiDBはPingCAP社が開発しているMySQL 5.7互換のクラウドネイティブ分散SQLデータベースです。
MySQL 5.7互換ということで簡単に使えそうな気もするものの、どれくらい互換があるのか、不安に感じる方もいると思います。以下を見ると、結構違いがありそうにも見えます。
さらにドキュメントを見る限り、5.7を気にすればいいいだけでなく、8.0の仕様についても一部取り入れていたり取り入れてなかったりするようです。
今回のブログではInsight Database TestingでMySQLアプリのTiDBへの移行で気になる互換性を確認してみたいと思います。
TiDBの環境はTiDB Cloudを使用
テスト用のTiDBの用意は、無料で試すことのできる TiDB Cloud を使用しました。サインアップして無料のクラスターを簡単に用意できます。
アカウント作成後は、ステップに従って必要情報を入力するのみで、簡単に接続可能なデータベースを用意できました。
MySQLからの移行を想定
Insight Database Testingでテストを行う際は、以下のような構成で行います。ソースのMySQLからはSQLを収集します。テスト対象はMySQLとTiDBのデータベースを用意し、SQLを実行した際の処理時間や、SELECT実行結果などの比較を行います。
この構成に対してあらかじめテーブルデータを用意し、テストを行います。
Insight Database Testingで確認
早速Insight Database Testingで確認してみます。今回、特にパフォーマンスを意識して環境を用意しているわけではないため、SQL実行時のパフォーマンス以外での挙動を評価できるかを確認してみます。
実行したSQLは以下の5つだけです。
select * from emp;
select d.deptno, d.dname, e.empno, coalesce(e.ename,'(no employee)') ename
from dept d left outer join emp e
on d.deptno=e.deptno;
select max(ename) from emp group by ename;
create table test as select * from emp;
select * from test;
このSQLをソースとなるMySQLで実行すると、実行されたSQLが蓄積されます。
なお、Insight Database TestingからTiDBへは、MySQLとして問題なく接続できました。 
それでは早速アセスメントを実行してみます。
Insight Database Testingではアセスメントを実行すると、上図のように、確認すべきSQLがすぐわかるようGUIが設計されています。
実行に失敗したSQLを見てみます。
SQLを確認すると以下のSQLがエラーとなっていました。
こちらの構文は、まだTiDBではサポートされていないようです。
実際、TiDBのGitHubに未実装であることが記載されています。
create table select from not supported. · Issue #4754 · pingcap/tidb · GitHub
この CREATE TABLE が失敗しているために、後続の SELECT も失敗していたということがわかりました。
続いて、結果が異なるSQL(Select結果が異なるSQL)を見てみます。
show databases という、直接実行しなかったSQLが実行されていました。どうやらMySQLクライアントで接続した際に、クライアントから勝手に実行されていたようです。
結果の相違を見ると、環境の違いのため、この違いについてはさほど気にする必要はなさそうです。
一方、以下のような順序違いはどうでしょう？
こちらは単純な順序違いのようです。ORDER BY がついていないので、順序は違ってもよいもの、とみなしてもよさそうです。Insight Database Testing ではこのような順序違いについて、アセスメント時に無視するアセスメントオプションもあります。(参考：アセスメントの新規作成 – Insight Database Testing Manual)
もう一つのSQLを見てみましょう。こちらも、一見、先ほどと同じ、単純な順序違いのようにも見えます。
が、実は、よくよく調べてみると、MySQL 5.7では GROUP BY では暗黙的にソートされることが仕様であったことが確認できます。(5.7の時点では非推奨で、8.0ではソートされなくなった)
MySQL :: MySQL 5.7 Reference Manual :: 1.3 What Is New in MySQL 5.7
そのため、5.7と互換がある、ということに従っているとすると、TiDBでも同様にソートされるべきなのですが、TiDBではソートされていなかったため、このような結果の違いとして検出されました。
MySQL 8.0 Compatibility · Issue #7968 · pingcap/tidb · GitHub
実際、上記に「Descending Indexes + GROUP BY no longer implying ORDER BY」という項目がありました。MySQL 8.0互換と考えると、問題はありませんが、5.7互換と考えると、仕様差がある例でした。
なお、性能劣化がある場合には、実行計画も並べて比較可能です。性能劣化が発生した際の調査などに活用可能です。
おわりに
MySQLアプリをTiDBへ移行するにあたり、アプリケーションで使用しているMySQLの機能を調べて、TiDBの仕様を調べて、互換性がどのくらいあるか(問題ないか)を調査するのは大変骨の折れる作業です。
本ブログでは、TiDBへの移行にあたって、MySQLで実行されていたSQLをInsight Database Testingで収集し、TiDBに対して評価実行することで、MySQLアプリの移行アセスメントに利用可能であることを確認しました。対障害性やスケール性能の確認に加えて、移行難易度がどれくらいあるかを確認する移行アセスメントは、移行の工程かなり重要なウェイトを占めます。Insight Database Testingを利用した移行アセスメントをぜひご活用ください。
Insight Database Testing をまだご利用いただいていない方で実際に試されたい場合は、製品の説明やデモ、トライアルなどについて
Insight Database Testingに関するお問い合わせ よりお問い合わせいただければと思います。
次回もどうぞお楽しみに！
