主キーの移行の概要

このページでは、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 番目のコンポーネントとして組み合わせる複合キーを作成します。これにより、順序付けされたキー値は保持されますが、大規模なホットスポットが発生しません。

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

次のステップ