主キーの移行の概要

このページでは、Spanner が主キーでどのように機能するかについて説明します。また、次のユースケースに主キーの移行戦略を提案します。

主キーの一般的なアプローチとして挙げられるのは、自動インクリメント数などのサロゲートキーを使用する方法です。このような主キーを使用すると、ビジネスロジックが変更された場合でも、現在と将来のキーを柔軟に最適化することができます。ボリュームが小さい単一インスタンスのデータベースでは、シーケンシャル キーは良好なパフォーマンスを発揮します。ただし、分散システムでは、シーケンシャル キーにおけるスケーリングは困難です。

Spanner のシーケンシャル主キー

Spanner では、すべてのテーブルに、そのテーブルの 1 つ以上の列からなる主キーがあります。テーブルの主キーは、テーブル内の各行を一意に識別します。Spanner は主キーを使用して、スプリットと呼ばれる行のグループを Spanner インスタンスのコンピューティング ノードに分散します。これは範囲シャーディングと呼ばれ、Spanner でクエリの並列化とスケーリングが可能になります。

単調な自動インクリメント キーなど、値が近接している主キーを持つ行は、同じスプリットに配置される傾向があります。これにより、利用可能なコンピューティング リソースとメモリリソースをスプリットがすべて使用できるホットスポットが作成される可能性があります。ホットスポットによりレイテンシが増加し、タイムアウトやトランザクションの中断につながる可能性があります。

Spanner の拡張性を活用し、ホットスポットを回避するために、Spanner には主キーの自動インクリメントの代替として組み込みソリューションが用意されています。

主キーに関する推奨事項

Spanner ではデフォルトで主キーに Universally Unique Identifier バージョン 4（UUIDv4）値を使用することをおすすめしています。UUID は、122 ビットのランダム データを使用する 128 ビットの識別子です。UUIDv4 値は非常に広範な値範囲を持ち、生成される場所に関係なく実質的に一意です。そのため、Spanner でホットスポット化を避けるための主キーとして適しています。

整数の主キーを使用すると、スペースの消費量が減り、アプリケーションの変更における複雑さが軽減されるため、整数の主キーを使用することをおすすめします。正のビット反転シーケンスを使用すると、64 ビットの正の整数空間に均等に分散される一意の主キー値を生成できます。

ホットスポットを防ぐために主キーを選択する方法については、スキーマ設計のベスト プラクティスをご覧ください。

移行戦略

アプリケーションのユースケースとニーズに応じて、主キーの移行戦略をデプロイできます。これらの移行戦略はそれぞれ、次の特徴があります。

  • 移行するキーの忠実性と正確性を確保する
  • 型や主キー値の変更といった、ダウンストリーム アプリケーションの変更を最小限に抑えます。
  • パフォーマンスと拡張性のために Spanner のベスト プラクティスを実装する
  • Spanner は、新しいデータの生成方法のみを変更し、既存のデータには影響しません。

UUID キー データベースの移行

UUID 主キーを使用するデータベースから Spanner に移行する場合について考えてみましょう。既存の UUID キーをソース データベースで文字列として構成し、そのまま Spanner にインポートします。UUID 値（特に v4）は、生成される場所に関係なくほぼ一意になります。

Spanner の GENERATE_UUID() 関数（GoogleSQL、PostgreSQL）を使用して、UUID キー データベースを移行できます。

UUID キー データベースの移行手順については、UUID キー列を移行するをご覧ください。

シーケンシャル キーを持つ単一インスタンス データベースの移行

MySQL の AUTO_INCREMENT、PostgreSQL の SERIAL、SQL Server または Oracle の標準 IDENTITY 型など、単調なシーケンシャル キーを使用する単一インスタンス データベースから移行する場合について考えてみましょう。

既存のキーの範囲内の値をスキップし、新しいビット反転キーを生成するように Spanner SEQUENCE オブジェクトを構成します。Spanner SEQUENCE オブジェクトによって生成されるビット反転キーは常にゼロより大きく、64 ビットの正の整数空間に均等に分散されます。

シーケンシャル キーを持つデータベースの移行手順については、自動生成されたシーケンシャル主キーを移行するをご覧ください。

ライブ カットオーバーをサポートするシーケンシャル キー データベースの移行

単調なシーケンシャル キーを持つ単一インスタンス データベースから Spanner に移行し、データベース システム間でライブ カットオーバーを行うなどのレプリケーション シナリオに対応するとします。

ソース データベース内の既存のキーの値範囲全体をスキップし、Spanner で新しいビット反転キーを生成するように Spanner SEQUENCE オブジェクトを構成します。Spanner SEQUENCE オブジェクトによって生成されるビット反転キーは常に 0 より大きくなりますが、順序付けはされません。

ライブ カットオーバーがサポートされているデータベースを移行する手順については、 Spanner とソース データベースを使用するをご覧ください。

アプリケーション ロジックに依存するシーケンシャル キー データベースの移行

単調なシーケンシャル キーを使用するデータベースから移行し、アプリケーション ロジックが主キーの順序に基づいて新しく作成されたデータの更新頻度を判断したり、シーケンス化したりしているとします。

シャード ID やハッシュなど均等に分散された値を最初のコンポーネントとして、連続する数値を 2 番目のコンポーネントとして組み合わせる複合キーを作成します。これにより、大規模なホットスポットが発生することなく、順序付けされたキー値が保持されます。

アプリケーション ロジックの依存関係があるシーケンシャル キー データベースを移行する手順については、独自の主キーを移行するをご覧ください。

次のステップ