🧩

新機能！Cloud Spanner Columnar Engineの紹介

に公開
Google Cloud
Google Cloud
Cloud Spanner
Cloud Spanner
tech

はじめに

Cloud Spanner はグローバル分散と強整合性を両立させた Google Cloud のフラッグシップ RDB です。2025 年 8 月、その Spanner に 「Columnar Engine」 がプレビューとして追加され、トランザクション（OLTP）と分析（OLAP）を 同じデータ・同じエンジン で扱えるようになりました。(現在プレビュー申し込み制です。公式ブログを参照。)

本記事では 「どんな機能か」 と 「どのようなユースケースで便利になるか」 に絞って解説します。

1. Columnar Engineとは？

行指向（既存 PAX） 列指向（Columnar Engine）
1 行を 1 ブロックに格納し、高頻度の単一行読み書きに最適 列ごとにデータを連続格納し、集計・スキャンを高速化

列指向 DB は、読み込む列を限定できるため I/O 削減・高圧縮・ベクトル化実行 で分析性能を高められる仕組みです。Spanner では従来の行指向フォーマット（PAX）の横に 列指向フォーマットを自動生成 し、クエリ特性を見て両エンジンを切り替える ハイブリッド構成 を採用しています。

2. なぜ必要だったのか

  • ETL／データコピー問題
    これまで OLTP データを分析するには BigQuery 等へ ETL する必要があり、ラグや二重管理コストが発生していました。
  • リアルタイム要件の高まり
    不正検知・IoT・マルチテナント SaaS ダッシュボードなどリアルタイムなデータ分析の需要が増加しています。

Columnar Engine は 同じテーブルに対して 2 種類のストレージエンジン を持つことで、OLTP パフォーマンスを維持したまま最大 200× の分析高速化 を実現します。(公式ブログ)

3. アーキテクチャ概要

3‑1. 列指向ストアの生成イメージ

(公式ブログ)によると、Spanner は 同じテーブルに対して行指向（PAX 形式）と列指向ストアへ同時に書き込み を行い、両フォーマットをリアルタイムで同期させています。これにより次のメリットが得られます。

  • 追加の ETL やデータコピーが不要になり、分析用 DWH とのレプリケーションラグを根本的に解消できる。
  • 行指向にも列指向にも TrueTime™ による統一された強整合性が適用されるため、トランザクション処理と分析クエリのどちらでも一貫した結果を取得できる。

ユーザーは従来どおり INSERT/UPDATE を実行するだけで、OLTP と高速 OLAP の両方をシームレスに活用できます。

3‑2. Vectorized Execution Vectorized Execution

  • 関数呼び出しをバッチ単位にまとめ CPU キャッシュ効率を向上
  • 列指向と相性が良く、集計・フィルタ処理をさらに加速

3‑3. Data Boost & BigQuery 連携

Spanner の分析専用コンピュート Data Boost や BigQuery の Federated Query から列ストアを自動利用でき、基盤を意識せずリアルタイム分析が可能になります。

4. 主な機能・特長

機能 概要
最大 200× スキャン性能 行ストア比。Scan‑bound クエリで特に効果大 (公式ブログ)
強い一貫性の維持 列ストアでも 強い一貫性とグローバル整合性を維持
ETLが不要になる 同一 DB 内で分析できるためコピー不要
明示ヒント @{scan_method=columnar} プレビュー期間はヒントで強制可能

4.1 なぜ 200× 速いのか

Columnar Engine が高速化できる理由を、 公式ブログで明言されている仕組み と、一般的な列指向 DB では定番の追加テクニックに分けて紹介します。後者の方は公式で言及されているわけではないので、あくまで私の推測です。

公式ブログで言及されている仕組み

  1. 必要な列だけを読む (I/O 削減)

    • 列ごとに連続してデータが並んでいるので、クエリで指定した列だけをディスクから読み込める。これだけで不要な I/O を大幅にカットできます。

  2. 圧縮率が高い (ストレージ & メモリ節約)

    • 同じ列には似たような値が並ぶため、圧縮が効きやすい。小さくなったデータをそのまま計算に使うことで転送も CPU 負荷も軽くなります。

  3. ベクトル化実行

    • 多くのデータを SIMD命令 で同じ計算を流れ作業でこなすことで、関数呼び出しや分岐のオーバーヘッドが激減します。

一般的な列指向DBの特徴から考察する理由

以下の3つは一般的な列指向DBで採用されているテクニックの紹介です。
Columnar Engine でこれらの技術が採用されているかどうかは不明です。

  1. Predicate Pushdown / Zone Map (不要ブロックをスキップ)

    • 各列チャンクに最小値・最大値のメタ情報を付け、WHERE 句に合わないチャンクはまるごと読み飛ばす。

  2. Late Materialization (最後まで列のまま処理)

    • 行を組み立てる（materialize）前にフィルタや集計を終わらせ、必要な列だけを最小限メモリに載せることでキャッシュ効率を保ちます。

5. ユースケース集

Columnar Engine が便利になりそうなユースケースの例を紹介します。

ユースケース なぜ Columnar Engine が効くか
リアルタイム分析 秒単位で更新される KPI ダッシュボードを ETL 無しで生成
不正検知 / レコメンド 高書込み率と複雑集計を同一 DB で両立し、レイテンシを短縮
IoT 向け時系列データの集計 高頻度インサートを維持しつつヒストリカルクエリを高速化

6. ベストプラクティスと注意点の予想

Spanner の Columnar Engine を最大限に活用するために、以下のベストプラクティスと注意点が予想されます。実際のところは私もまだ触っていないので違うかもしれないことに留意してください。

ベストプラクティス

  1. 必要列を明示する（SELECT * を避ける）

    • Columnar Engine はクエリで参照する列だけをスキャンするため、効率よく高速にデータの集計や分析が可能です。カラムナストレージでは、分析クエリがアクセスする列が少ない場合、関連する列のみをディスクから読み取るため、I/O 操作を大幅に削減できます。
    • SELECT * を使うと不要な列も読み込むことになり、I/O コストと実行時間が増大する可能性があります。
    • たとえば売上テーブルから「売上日」と「金額」だけを集計したい場合は、SELECT sales_date, amount FROM … のように列を限定しましょう。

  2. クエリプランを確認し、ボトルネックを特定する

    • Spanner のクエリプラン（EXPLAINなどを用いて）を確認し、Table Scan が律速になっている分析クエリに Columnar Engine が特に効果的です。
    • 日次レポートやダッシュボードなど、大規模なデータセットに対して高速な集計とスキャンが必要なワークロードに向いています。

  3. データ型を揃えて圧縮効率を最大化する

    • カラムナストレージは、列ごとにデータが格納されるため、同じ型の類似したデータが揃うことで高いデータ圧縮率を実現します。これにより、より多くのデータをメモリに収めることができ、読み込むバイト数も減らすことができます。
    • 例えば、TRUE/FALSE しか入らない列は BOOL で定義するなど、データ型を適切に定義し、整数と文字列を混在させないようスキーマを整理することは、圧縮効率の最大化に寄与します。

  4. Append‑Only 設計への理解（Spannerのハイブリッド特性）

    • 一般に、カラムナ形式は列方向にデータをまとめて扱うことで集計作業を得意としますが、特定の行を抜き出して更新したり削除したりする操作は苦手とされます。そのため、追記中心 (Append‑Only) のワークロードで最も性能を発揮すると言えます。
    • しかし、Spanner の Columnar Engine は、既存の行指向ストレージ（PAX）と並行してカラムナ形式を統合するハイブリッドアーキテクチャを採用しています。データの書き込みはPAXとカラムナの両方に行われるため、Spanner は OLTP 性能を維持しつつ、頻繁な更新を伴う運用データに対しても分析クエリを最大200倍高速化できるとされています。
    • この設計により、Spanner は「高頻度のトランザクション書き込みとリッチな分析を同じ場所で実行できる」と説明されており、従来の OLTP システムと分析システムを分離し、データ転送や複雑な ETL パイプラインが必要になるという課題を解決します。

  5. BigQuery との連携を活用する

    • Spanner の Columnar Engine は、BigQuery との統合が強化されており、BigQuery のフェデレーテッドクエリや、分析ワークロード向けのフルマネージドの伸縮自在なコンピュートサービスであるData Boost を通じて Spanner データをそのまま分析できます。
    • これにより、複雑な ETL パイプラインを介さず、リアルタイムに近い形で運用データに対して豊富な分析を行うことが可能になります。

注意点

  1. ストレージコストの試算とモニタリング

    • Spanner の Columnar Engine は、既存の行指向ストレージ（PAX）に加えてカラムナ形式を統合しています。データはPAXとカラムナの両方に書き込まれるため、論理的には同じデータに対してストレージの増量が発生することになります。
    • カラムナストレージは高いデータ圧縮率を持ちますが、それでも追加のストレージ容量が必要となるため、ストレージコストへの影響を事前に試算し、モニタリングで把握することが重要です。

  2. プレビュー版であることの認識

    • Spanner Columnar Engine は現在プレビュー版として提供されており、利用申し込みを受け付けている段階です。本番環境での利用には、Google Cloud からの正式リリースアナウンスメントを注視し、十分な検証を行うことが推奨されます。

まとめ

Cloud Spanner Columnar Engine は トランザクション DB の信頼性 と 列指向による分析性能 を同時に手に入れ、ETL／二重運用の負担を解消する強力なアップデートです。リアルタイム性が求められるサービスでは、まずは Scan‑bound なクエリを対象に試験導入 し、レイテンシと運用コストのトレードオフを評価してみてください。

プレビュー段階のため本番適用には慎重な検証が必須ですが、「OLTP と OLAP の統合」 という長年の課題に対する有力なソリューションとして注目に値します。

参考リンク

Discussion