【実務・中級編】 BYTES型の最適化 – Cloud Spanner

Cloud SpannerにおけるBYTES型の極意：大規模分散ストレージを「殺さない」ためのデータ設計

Cloud Spannerの設計レビューをしていると、必ずと言っていいほど「BYTES型」の扱いが甘い設計に出くわす。

「とりあえずバイナリを突っ込んでおけばいいだろう」という安易な実装は、Spannerの分散アーキテクチャの急所を突く。結果、スプリットの肥大化、レプリケーションの遅延、そして予期せぬパフォーマンス低下という「負の遺産」を背負うことになる。

今日は、Spannerの深淵を知るエンジニアのために、BYTES型とどう向き合うべきか、その極意を伝授する。

—

1. なぜ「BYTES型」がパフォーマンスを左右するのか

Spannerのストレージ層において、データは`Key`と`Value`で構成される。主キー（Primary Key）にBYTES型を含める場合、その値はそのままインデックスの並び順に直結する。

BYTES型は可変長であり、最大10MBまで格納可能だが、「上限があるからといって、無制限に詰め込んでいい」わけではない。

Splitの肥大化: 1つのスプリット（Spannerのデータ分割単位）が肥大化すると、負荷分散の効率が落ちる。
ソートコスト: インデックスの主キーとして巨大なBYTESを置くと、比較・ソートコストが計算資源を食いつぶす。
通信オーバーヘッド: 巨大なBYTES値を頻繁にフェッチすると、ネットワークI/Oがボトルネックになる。

2. 堅牢な設計パターン：BYTES型をどう扱うべきか

実務では、以下の3つのパターンを使い分けるのが「プロの作法」だ。

A. 小規模バイナリ（数KB以下）：直接格納

ID、フラグ、ハッシュ値など、常にデータ量が変わらず小さい場合は、素直に`BYTES(N)`で定義する。

— 良い設計例：固定長に近い、または十分小さい値
CREATE TABLE UserMetadata (
UserId INT64 NOT NULL,
AvatarHash BYTES(32), — SHA-256ハッシュなら32バイトで固定
) PRIMARY KEY (UserId);

B. 大規模バイナリ（数MB級）：外部ストアへのオフロード

数MBに達するようなバイナリ（画像、ドキュメントなど）をSpannerに直接置くのはアンチパターンだ。Spannerはトランザクション性能には極めて優れているが、巨大なBLOBを捌くためのストレージではない。

推奨: Cloud Storage (GCS) に実体を保存し、Spannerにはその「URI（文字列）」または「オブジェクトID」だけを格納する。

C. 準大規模バイナリ（数十KB〜数百KB）：テーブル分離

テーブルのデータアクセスの大半が、そのバイナリを必要としない場合、カラムを別テーブルに切り出す（Vertical Partitioning）。

— メインのプロファイルデータ
CREATE TABLE Users (
UserId INT64 NOT NULL,
Name STRING(MAX),
) PRIMARY KEY (UserId);

— 滅多に参照しない巨大な設定データのみ別テーブルへ
CREATE TABLE UserLargeSettings (
UserId INT64 NOT NULL,
SettingsBlob BYTES(MAX),
) PRIMARY KEY (UserId),
INTERLEAVE IN PARENT Users ON DELETE CASCADE;

—

3. パフォーマンスを最大化するための「制約」と「注意点」

1. `BYTES(MAX)`の過信を捨てる

`BYTES(MAX)`と書けばどんなデータでも入るが、バリデーションがアプリケーション層任せになる。Spannerが提供するデータサイズの制限を意識し、論理的な上限をアプリケーション設計段階で規定しておくこと。

2. インデックス設計の罠

BYTES型のカラムをインデックスに追加する場合、デフォルトのプレフィックス長に注意せよ。巨大なBYTESをプレフィックスにすると、インデックスサイズが膨れ上がり、メモリ（キャッシュ）を圧迫する。

3. トランザクションサイズの上限

Spannerのトランザクションあたりの最大サイズ制限（通常100MB前後）を忘れてはならない。BYTES型を多用するトランザクションを組む際、この制限に触れると「トランザクションが大きすぎます」というエラーでシステムが停止する。

—

結論：アーキテクトとしての思考法

BYTES型を設計するとき、自問自答すべきは以下の3点だ。

1. 「このデータは、本当に主キーの一部である必要があるか？」（BYTESをPKにすると、インデックスが巨大化し、スキャンコストが激増する）
2. 「このデータは頻繁に更新されるか？」（巨大なBYTESの更新は、レプリケーションの負荷を著しく高める）
3. 「このデータはCloud Storageで代替できないか？」（Spannerをストレージの万能選手にしないこと）

Spannerを使いこなすということは、データの「質」と「量」を冷徹に見極めることだ。BYTES型の扱いに迷ったら、一度立ち止まって「そのデータは、Spannerのトランザクションの一貫性の中に存在すべきものか？」を再考してほしい。

それができれば、君のシステムはどんな高負荷にも耐えうる、真に堅牢なアーキテクチャへと昇華するはずだ。

次は、クエリ実行計画の読み方について話そうか。あれもまた、奥が深い。