By name: scalardb-transaction description: ScalarDBのトランザクション設計を行います。トランザクション境界定義、パターン選定（単一集約内/2PC/Saga/ハイブリッド）、OCC競合率評価、バッチ処理設計、v3.17最適化適用計画を含みます。ワークフローStep 05（トランザクション設計）で使用します。
ScalarDB Transaction Design Skill
目的
ScalarDB のトランザクションパターンを選定・設計し、以下を生成する:
- トランザクション境界定義
- パターン選定結果と根拠
- OCC競合率評価
- バッチ処理設計
- v3.17 最適化適用計画
- エラーハンドリング・リトライ戦略
リファレンス資料
| 資料 | パス | 参照内容 |
|---|---|---|
| トランザクションモデル | research/07_transaction_model.md |
7つのトランザクションパターン |
| バッチ処理 | research/09_batch_processing.md |
バッチ有効/無効ケース、チャンクサイズ |
| ScalarDB 3.17 | research/13_scalardb_317_deep_dive.md |
最適化機能の詳細 |
| ワークフロー05 | workflow/05_transaction_design.md |
Step 05 手順 |
実行フロー
Stage 1: トランザクション境界の定義
Step 04（データモデル）の結果を基に、各ビジネスプロセスのトランザクション境界を定義する。
トランザクション境界テンプレート:
| トランザクション名 | ビジネスプロセス | 関与集約 | 関与テーブル | 操作種別 |
|---|---|---|---|---|
| Read/Write/ReadWrite |
Stage 2: トランザクションパターン選定
各トランザクションに対してパターンを選定:
| パターン | 適用条件 | ScalarDB API |
|---|---|---|
| 単一集約内 | 1サービス・1テーブル | DistributedTransaction |
| 単一サービス複数テーブル | 1サービス・複数テーブル | DistributedTransaction |
| 2PC（2サービス） | 2サービス間ACID | TwoPhaseCommitTransaction |
| 2PC（3サービス） | 3サービス間ACID（上限） | TwoPhaseCommitTransaction |
| Saga | 結果整合性で十分 | アプリケーション実装 |
| Saga + 部分2PC | 一部ACIDが必要 | ハイブリッド |
パターン選定マトリクス:
| トランザクション名 | 選定パターン | 根拠 | リスク |
|---|---|---|---|
Stage 3: OCC 競合率評価
楽観的並行性制御（OCC）の競合率を評価し、対策を検討する。
競合率評価テンプレート:
| トランザクション | 対象レコード | 同時実行数 | 推定競合率 | 許容範囲 | 対策 |
|---|---|---|---|---|---|
| < 5% |
競合率が高い場合の対策:
- Partition Key の見直し（アクセス分散）
- トランザクション範囲の縮小
- リトライ戦略の調整
- ビジネスプロセスの再設計（Saga化検討）
Stage 4: バッチ処理設計
バッチ処理テンプレート:
| バッチ名 | 処理内容 | 対象テーブル | 予想レコード数 | チャンクサイズ | トランザクション範囲 |
|---|---|---|---|---|---|
| 100-1000推奨 | チャンク単位 |
ScalarDB バッチ処理の制約:
- 長時間トランザクションは OCC 競合リスクが高い
- チャンク単位でコミットする設計が必須
- Batch Operations（v3.17）で複数操作を一括送信可能
Stage 5: v3.17 最適化適用計画
| 最適化機能 | 適用対象 | 効果 | 設定 |
|---|---|---|---|
| Piggyback Begin | 全トランザクション | ラウンドトリップ -1 | 有効化推奨 |
| Write Buffering | 書き込み多いTx | ネットワーク呼出削減 | 対象Txで有効化 |
| Batch Operations | バッチ処理 | スループット向上 | バッチ処理で使用 |
| Tx Metadata Decoupling | 小レコードテーブル | ストレージ効率化 | READレイテンシ影響を評価 |
Stage 6: エラーハンドリング・リトライ戦略
エラーハンドリングテンプレート:
| 例外 | 原因 | 対応 | リトライ |
|---|---|---|---|
CrudConflictException |
OCC競合 | リトライ | Yes（指数バックオフ） |
CommitConflictException |
コミット時競合 | リトライ | Yes（指数バックオフ） |
UnknownTransactionStatusException |
状態不明 | 確認→リトライ or 補償 | 条件付き |
CommitException |
コミット失敗 | abort→リトライ | Yes |
UnsatisfiedConditionException |
条件未達 | ビジネスロジック判断 | No |
リトライ設定テンプレート:
| パラメータ | 推奨値 | 説明 |
|---|---|---|
| 最大リトライ回数 | 3-5 | 過度なリトライは避ける |
| 初回待機時間 | 100ms | 指数バックオフの起点 |
| 最大待機時間 | 5000ms | 上限 |
| バックオフ係数 | 2.0 | 倍増 |
| ジッター | ±50ms | 同時リトライの分散 |
Stage 7: 出力
成果物を output/phase2/05_transaction_design.md に出力。
使用例
/plan-step 05
Step 04 のデータモデルに基づいてトランザクション設計を行ってください。
特に以下のプロセスの設計を重視:
- 注文確定（注文 + 在庫 + 決済の3サービス跨ぎ）
- ポイント付与（結果整合性で可）
- 月次バッチ集計