このページでは、MySQL スキーマを Spanner スキーマに移行する方法について説明します。既存の MySQL スキーマから Spanner スキーマを構築するには、Spanner 移行ツールを使用することをおすすめします。このツールは、ほとんどの MySQL データ型を Spanner 型にマッピングします。また、選択肢をハイライト表示し、移行に関する潜在的な問題を回避するための候補を提示します。
データ型の比較
次の MySQL データ型のリストを、Spanner の同等のデータ型にマッピングします。
| MySQL のデータ型 | Spanner の対応するデータ型 | 注 |
|---|---|---|
INTEGER、INT、BIGINT、MEDIUMINT、SMALLINT、TINYINT |
INT64 |
|
TINYINT、BOOL、BOOLEAN |
BOOLEAN |
TINYINT(1) 値は、ブール値 true（ゼロ以外）または false（0）を表すために使用されます。 |
BIT
|
BOOLEAN、INT64 |
|
CHAR、VARCHAR、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT |
STRING |
Spanner では全体的に Unicode UTF8 文字列が使用され、照合順序は構成できません。VARCHAR では最大 65,535 バイトがサポートされ、Spanner では最大 2,621,440 文字がサポートされます。
|
FLOAT |
FLOAT32 |
|
DOUBLE |
FLOAT64 |
|
DECIMAL、NUMERIC |
NUMERIC
|
MySQL では、列宣言で定義されているように、NUMERIC データ型と DECIMAL データ型は最大 65 桁の精度と尺度をサポートします。Spanner NUMERIC のデータ型は、最大 38 桁の精度と 10 進 9 桁の尺度をサポートします。精度の向上が必要な場合は、代替メカニズムについて任意の精度の数値データの保存をご覧ください。 |
BINARY、VARBINARY、TINYBLOB、BLOB、MEDIUMBLOB、LONGBLOB |
BYTES |
小さなオブジェクト（10 MiB 未満）は BYTES として保存できます。より大きなオブジェクトを保存する際には、Cloud Storage などの代替 Google Cloud サービスの使用を検討してください。 |
DATE |
DATE |
Spanner と MySQL は、どちらも日付に「yyyy-mm-dd」形式を使用するため、変換する必要がありません。日付を書式設定済み文字列に変換するための SQL 関数が提供されています。 |
DATETIME、TIMESTAMP |
TIMESTAMP |
Spanner では時間はタイムゾーンから切り離して保存されます。タイムゾーンを保存する必要がある場合は、個別の STRING 列を使用する必要があります。タイムスタンプをタイムゾーン付きの書式設定済み文字列に変換するための SQL 関数が提供されています。 |
TEXT、TINYTEXT、ENUM |
STRING |
小さな TEXT 値（10 MiB 未満）は STRING として保存できます。より大きな TEXT 値をサポートするには、Cloud Storage などの代替 Google Cloud サービスを使用することを検討してください。 |
ENUM |
STRING |
ENUM 値の検証は、アプリケーションで実行する必要があります。 |
SET |
ARRAY<STRING> |
SET 要素値の検証は、アプリケーションで実行する必要があります。 |
LONGBLOB、MEDIUMBLOB |
オブジェクトへの URI を含む BYTES または STRING |
小さなオブジェクト（10 MiB 未満）は BYTES として保存できます。より大きなオブジェクトを保存する際には、Cloud Storage などの代替 Google Cloud サービスの使用を検討してください。 |
LONGTEXT、MEDIUMTEXT |
STRING（データまたは外部オブジェクトへの URI を含む） |
小さなオブジェクト（2,621,440 文字未満）は STRING として保存できます。より大きなオブジェクトを保存する際には、Cloud Storage などの代替 Google Cloud サービスの使用を検討してください。 |
JSON |
JSON
|
小さな JSON 文字列（2,621,440 文字未満）は JSON として保存できます。より大きなオブジェクトを保存する際には、Cloud Storage などの代替 Google Cloud サービスの使用を検討してください。 |
GEOMETRY、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTIPOLYGON、GEOMETRYCOLLECTION |
STRING、ARRAY |
Spanner は地理空間データ型をサポートしていません。標準のデータ型を使用してこのデータを保存し、検索またはフィルタリング ロジックをアプリケーションに実装する必要があります。 |
多くの場合、複数の MySQL 型が 1 つの Spanner 型にマッピングされます。これは、MySQL には同じコンセプトに対して長さの上限が異なる一連のデータ型があり、Spanner には比較的大きな上限が 1 つしかないためです。
以下の例を考えてみましょう。
MySQL には
TEXT、TINYTEXT、MEDIUMTEXT、LONGTEXTがあります。Spanner には、文字長のパラメータを持つ単一の型STRINGがあり、最大 2,621,440 文字の任意の値に設定できます。MySQL には、
INTEGER、INT、BIGINT、MEDIUMINT、SMALLINT、TINYINTがあります。Spanner には、8 バイトの符号付き整数値を格納する単一の型INT64があります。主な違いは、Spanner のINT64はMEDIUMINT、SMALLINT、TINYINTよりも多くのストレージを使用することです。また、INT64はMEDIUMINT、SMALLINT、TINYINTの範囲制限をキャプチャしませんが、CHECK制約を追加することで適用できます。
Spanner は地理空間型をサポートしていません。これらの型の値を格納するには、文字列、バイト、配列としてエンコードします。フィルタリング、オペレーション、関数はすべてアプリケーション レベルで実行する必要があります。
クエリ
Spanner は、拡張機能を含む ANSI 2011 SQL に対応し、データの変換や集計に役立つ多数の関数と演算子を備えています。MySQL 固有の構文、関数、型を使用する SQL クエリについては、Spanner との互換性を保つために変換する必要があります。
Spanner では構造化データを列定義として使用することはできませんが、ARRAY<> 型と STRUCT<> 型を使用すれば、SQL クエリで構造化データを扱うことができます。たとえば、1 つのクエリで STRUCT の ARRAY を使用して（事前結合されたデータを利用して）、アーティストのすべてのアルバムを返せます。詳細については、クエリ構文に関するドキュメントのサブクエリをご覧ください。
SQL クエリは、 Google Cloud コンソールの [Spanner Studio] ページで実行できます。一般に、大きなテーブルを対象としてテーブル全体のスキャンを実行するクエリには非常にコストがかかるため、使用は控えめにする必要があります。SQL クエリの最適化の詳細については、SQL のベスト プラクティスのドキュメントをご覧ください。
ストアド プロシージャとトリガー
Spanner は、データベース レベルでのユーザーコードの実行をサポートしていません。スキーマ移行の一環として、MySQL データベース レベルで実装したストアド プロシージャとビジネス ロジック トリガーをアプリケーションに移動します。
シーケンス
Spanner は、主キー値を生成するデフォルトの方法として UUID バージョン 4 を使用することを推奨しています。GENERATE_UUID() 関数は、STRING 型で表される UUID バージョン 4 の値を返します。
整数値を生成する必要がある場合は、Spanner でビット反転した正のシーケンスがサポートされ、これにより 64 ビットの正の数空間に均等に分散する値が生成されます。ホットスポット化の問題を回避するため、これらの数値を使用できます。
詳細については、主キーのデフォルト値の戦略をご覧ください。