Snowflake Hybrid TablesでOLTP+OLAPを統合する設計と実践

Hybrid Tablesは、SnowflakeのUnistoreアーキテクチャの中核機能で、 低レイテンシの行単位操作（OLTP）と大規模分析クエリ（OLAP）を 同一テーブルで実現するテーブル型です。主キー（PRIMARY KEY）が必須であり、行指向のストレージ構造と インデックスを備えることで、単一行のルックアップやポイント更新をミリ秒レベルで処理します。

Hybrid Tablesのアーキテクチャ

通常テーブル (Standard Table)
  └─ 列指向マイクロパーティション
       └─ 大規模スキャン・集計に最適化
       └─ 単一行ルックアップは非効率

Hybrid Table
  ├─ 行指向ストレージ（主キーインデックス付き）
  │    └─ 単一行 SELECT / UPDATE / DELETE がミリ秒で完了
  │    └─ 参照整合性制約（FOREIGN KEY）をサポート
  │
  └─ 列指向ストレージ（バックグラウンド同期）
       └─ SELECT * / 集計クエリはこちらから読み取り
       └─ Snowflakeが自動的に行→列の同期を実行

CREATE HYBRID TABLEの構文

-- 基本的なHybrid Table（主キー必須）
CREATE OR REPLACE HYBRID TABLE app_db.public.users (
  user_id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE,
  display_name VARCHAR(100),
  status VARCHAR(20) DEFAULT 'active',
  created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),
  last_login TIMESTAMP_NTZ,
  metadata VARIANT
);

-- 複合主キーのHybrid Table
CREATE OR REPLACE HYBRID TABLE app_db.public.user_sessions (
  user_id INT,
  session_id VARCHAR(64),
  started_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),
  expires_at TIMESTAMP_NTZ,
  ip_address VARCHAR(45),
  user_agent VARCHAR(500),
  PRIMARY KEY (user_id, session_id),
  FOREIGN KEY (user_id) REFERENCES app_db.public.users(user_id)
);

-- セカンダリインデックスの追加
CREATE INDEX idx_users_email ON app_db.public.users (email);
CREATE INDEX idx_sessions_expires ON app_db.public.user_sessions (expires_at);

主キーの設計指針

DML操作のパターン

-- 単一行の挿入（低レイテンシ）
INSERT INTO app_db.public.users (user_id, email, display_name)
VALUES (1001, '[email protected]', 'Alice');

-- 主キーによるポイント更新（ミリ秒レベル）
UPDATE app_db.public.users
SET last_login = CURRENT_TIMESTAMP(), status = 'active'
WHERE user_id = 1001;

-- 主キーによる単一行削除
DELETE FROM app_db.public.users WHERE user_id = 1001;

-- MERGE（upsert）: アプリケーション側のidempotency確保
MERGE INTO app_db.public.users t
USING (SELECT 1001 AS user_id, '[email protected]' AS email, 'Alice' AS name) s
ON t.user_id = s.user_id
WHEN MATCHED THEN UPDATE SET t.last_login = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT (user_id, email, display_name) VALUES (s.user_id, s.email, s.name);

-- 分析クエリ（OLAP）も同一テーブルで実行可能
SELECT
  DATE_TRUNC('DAY', created_at) AS signup_date,
  COUNT(*) AS new_users,
  COUNT_IF(status = 'active') AS active_users
FROM app_db.public.users
GROUP BY signup_date
ORDER BY signup_date DESC;

同時実行制御とロック

Hybrid Tablesは行レベルのロック機構を備えています。通常のSnowflakeテーブルは マイクロパーティション単位のスナップショット分離（MVCC）で同時実行を処理しますが、 Hybrid Tablesは行レベルで悲観的ロックを取得し、 同一行への同時更新を直列化します。

• 異なる行への同時DMLは並行して実行される
• 同一行への同時UPDATEはロック待ちが発生する
• デッドロック検出機構があり、自動的に片方のトランザクションをアボートする
• 読み取りクエリ（SELECT）はロックを取得しないため、書き込みをブロックしない

参照整合性制約

-- FOREIGN KEY制約（Hybrid Tables間でのみ有効）
CREATE OR REPLACE HYBRID TABLE app_db.public.orders (
  order_id INT PRIMARY KEY AUTOINCREMENT,
  user_id INT NOT NULL,
  total_amount NUMBER(12,2) NOT NULL,
  order_status VARCHAR(20) DEFAULT 'pending',
  created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),
  FOREIGN KEY (user_id) REFERENCES app_db.public.users(user_id)
);

-- NOT NULL, UNIQUE, DEFAULT 制約もサポート
-- ただしCHECK制約は未サポート

通常テーブルとHybrid Tablesの比較

制約と注意事項

• 主キー（PRIMARY KEY）の定義が必須であり、主キーなしのHybrid Tableは作成できない
• Clustering Keysは設定不可
• Materialized Viewの作成は不可
• FOREIGN KEYはHybrid Tables間でのみ有効（通常テーブルとの間では設定不可）
• Time Travel, Fail-safeの機能が通常テーブルと異なる場合がある
• 大量バッチINSERT（数百万行）よりも、少量の高頻度DMLに適している

ベストプラクティス

• OLTP用途のテーブルのみHybrid Tableにする：ユーザーマスタ・セッション管理・在庫カウンターなど、ポイント操作が主体のテーブルに限定する
• 大規模分析用テーブルは通常テーブルを使い続ける：数十億行のファクトテーブルには通常テーブル + Clustering Keysが適している
• セカンダリインデックスは慎重に追加：インデックスが多いほどDML性能が低下するため、頻繁にクエリされる列のみに絞る
• FOREIGN KEYでデータ整合性を担保：アプリケーション層だけでなくDB層でも整合性を強制し、不整合データの混入を防ぐ

問題で確認

よくある質問