デベロッパー

MySQL から Cloud Spanner に移行するためのヒント

2021年6月18日

https://storage.googleapis.com/gweb-cloudblog-publish/images/Spanner_blog_1.max-2200x2200.png

Google Cloud Japan Team

※この投稿は米国時間 2021 年 6 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

MySQL は 1995 年に初めてリリースされてから、数多くのデータストレージのニーズに対応する事実上のデータベースになってきました。それだけでなく、リレーショナルデータベース管理システムとトランザクションデータ処理に関しては、特によく知られているデータベースとして長年にわたって多くの注目を集めてきました。

小売、e コマース、銀行業務のアプリケーションは、トランザクションのニーズに合ったリレーショナルデータベースを使用できるかどうかにかなり依存しています。こうしたアプリケーションの多くが MySQL で構築されている理由は、その柔軟性、オープンソースな性質、強力なコミュニティサポートによります。

リレーショナルデータベース（MySQL や PostgreSQL など）、NoSQL データベース（Cassandra など）、グリーングラスワークロードのいずれから移行する場合も、多数の企業が Cloud Spanner を活用してきました。こうした企業が Cloud Spanner に求めているメリットとしては、高可用性 SLA（リージョンインスタンスの場合は 99.99%、マルチリージョンインスタンスの場合は 99.999%）、無制限のスケーリング、低い運用オーバーヘッドなどによって、パッチ適用や、メンテナンスなどの計画ダウンタイムが不要になることが挙げられます。これらのメリットはほんの一例です。

Spanner に関連したツールやオープンソースエコシステムは、Spanner が導入されて以来、進化と成長を続けてきました。HarbourBridge はこのエコシステムの一部であり、お客様が MySQL や PostgreSQL の既存スキーマを Cloud Spanner スキーマに移植できるようにすることを目的としています。

アプリケーション移行のヒント

HarbourBridge をはじめとする便利なツールが用意されていますが、データベースの移行は一筋縄ではいきません。ここでは、MySQL から Spanner に移行する際に注意すべき点と、それらに対処するためにアプリケーションロジックを更新する方法をご紹介します。

注: 次のスニペットでは、Cloud Spanner 用の PHP クライアントを使用しています。いくつかのスニペットは、Searce の仲間たちが取り組んできた Magento ポートの一部を参照しています。このオペレーションを理解すれば、Cloud Spanner がサポートする他の言語でも同じものを実装できるはずです。

Cloud Spanner は厳密なデータ型を適用

MySQL クエリでは、属性の値を文字列または整数として参照できます。以下に例を示します。

select * from catalog_eav_attribute where attribute_id = 46;
select * from catalog_eav_attribute where attribute_id = "46";

どちらも有効で同等です。

Cloud Spanner では、文字列表現を使用して整数型を参照しようとすると、クエリエラーが返されます。

Cloud Spanner の実際のクエリの例を次に示します。

select * from catalog_eav_attribute where attribute_id = 46; -- 動作します
select * from catalog_eav_attribute where attribute_id = “46”; -- 「46」の文字列を指定しているため失敗します

このような変換をサポートするために、次のような関数を使用できます。

読み込んでいます...

主キーに順次 ID を使用することは Spanner のベストプラクティスではない

Cloud Spanner ではシーケンスジェネレータは実装されません。また、ホットスポットが発生する可能性があるため、順次 ID の使用は Cloud Spanner のベストプラクティスではありません。

代わりに、UUID や同様のメカニズムを使用して一意の主キーを生成し、値が連続しないようにすることができます。詳しくは、こちらの記事をご覧ください。

既存のすべての主キーを UUID パターンに変換するには、こちらのスニペットを使用してスキーマを変更します。

このコードスニペットを使用して、自動インクリメントの UUID を生成するようにアプリケーションコードを変更できます。これを行うには、PHP 組み込みの uniqid 関数を使用するなど、他の方法もあります。

読み込んでいます...

暗黙的なキャストとフィールドデータ型の明示的なキャストの必要性

MySQL と Cloud Spanner はともに SQL 標準に準拠しているため、大半のクエリ構文は同じです。大きな違いとしては、Cloud Spanner のフィールド型が、こちらで説明されているデータ型から適切なものに暗黙的にキャストされることが挙げられます。フィールド型の暗黙的なキャストが失敗すると、Spanner から読み取りエラーが返されます。そのため、SELECT 文を発行する際に適切な型にキャストする方が安全です。

それぞれのデータ型にキャストするようにアプリケーションコードを変更してからクエリを実行します。

読み込んでいます...