
2026/08/02 1:01
PgTestDB はテンプレートクローン方式によるテストで高速です
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Peter Downs は、River の既存のスキーマベースのテスト手法を、Postgres のテンプレートデータベースを 8kB のチャンク単位で複製するネイティブ機能を活用する Go/Postgres パッケージ
pgtestdb と比較しました。両アプローチとも初期セットアップ時間はほぼ同等(~100ms)ですが、River の手法の方が全体的なテストスイートの実行速度が著しく高速です。並列化されたテスト間で既存のスキーマをプールして再利用し、毎回ゼロから新しいインスタンスを生成するのではなく、River はフルスイート完了時間を pgtestdb を使用時の~51 秒から~14.5 秒に縮め、3.5 倍の速度向上を実現しました。この戦略により、River はデバッグのためにテスト状態を保持し続けることができ、listen/notify などのデータベース全体レベルの機能を含む複雑なシナリオをサポートできます。pgtestdb は依然として単純なエンドツーエンドジョブテストのための軽量な代替手段として有効ですが、River は堅牢な分離性と設定管理を確保するために、独自の実装によるバージョン管理型のスキーマ再利用アプローチを継続して使用します。本文
pgtestdb と River テストスイートのパフォーマンス比較と最適化
昨日、Peter Downs が開発した Go/Postgres テストパッケージ「pgtestdb」について再考しました。このツールは PostgreSQL の固有機能である「テンプレートデータベース」を活用しており、標準的な psql コマンドラインから即座に試すことができます:
CREATE DATABASE dbname TEMPLATE template_to_copy;
pgtestdb の高速化の仕組み
テンプレートコピー処理は非常に高速です。ゼロからのマイグレーションや重い Docker ベースの手法と比較しても格段に优越しています。その原理は以下の通りです:
- 低レベルなコピー:Postgres がテンプレートに含まれるリレーションを列挙し、8KB ページ単位でヘープ、インデックス、カタログファイルなどをそのままコピーします。
- 設定不要:特別な設定なしで動作します。
River テストスイートとの統合
私は pgtestdb を River テストスイートに Codex を使って統合し、実用性を確認しました。River のテスト手法は以下の「ゴールドスタンダード」として定評があります:
- テスト状態の保持:失敗してもテストステートを残すため、後からの調査が容易です。
- 広範囲なテスト対応:
などの DB 全体機能もテスト可能です。listen/notify - 境界条件の検証:トランザクション間の相互作用やロールバックに関する検証に適しています。
パフォーマンス比較結果
Postgres ではスキーマの方が軽量ですが、スキーマ複製(クローン)が不可能なためマイグレーションが必要でした。一方、pgtestdb は明らかな優位性を持ちます。私が得た設定時間の比較結果は以下の通りです:
| 方法 | サンプル数 | 平均時間 | p90 | p95 | 最大値 |
|---|---|---|---|---|---|
| pgtestdb クローン | 466 | 98.4ms | 247.4ms | 299.5ms | 465.1ms |
| スキーマ作成+マイグレーション | 81 | 99.4ms | 152.1ms | 209.0ms | 327.0ms |
重要な発見:
- 両者のセットアップ時間はほぼ同等(約 100ms)で、非常に短いものでした。
- 「新しい DB 作成は遅い」という従来の認識とは異なり、pgtestdb も同等の高速性を発揮しました。
運用方針について
River テストは引き続き既存のスキーマベース方法を使用します:
- 理由:すでに高速であり、River の設定動作確認にも有益だからです。
- 推奨事項:文書には pgtestdb を記載し、特にエンドツーエンドテスト(例:クライアントからジョブ挿入 → ワーカー完了)を目指すユーザーに重点的に案内します。
再利用による最適化
上記の結果は単一の実行タイムですが、全体としてのテストスイート実行時間はスキーマベースアプローチの方が優れています。
| 方法 | 壁面時間 |
|---|---|
| pgtestdb クローン | 51.07 秒 |
| スキーマ作成+マイグレーション | 14.54 秒 |
高速化の要因:
- スキーマ自体の軽さではなく、River テストヘルパーの有用な最適化機能によるものです。
- 仕組み:必要な数のスキーマをプールの形で保持し、利用可能な場合は新規作成せずクリーンして再利用します。
注意点と実装難易度
このアプローチは「簡単」ではありません:
- バージョン管理:複数バージョンのスキーマをまたぐテストでは、各ケースが期待するスキーマのみを再利用する必要があります。
- 開発コスト:River の実装(LLM 登場前の手動作成)はバグを絞り出すのに数日を要しました。
将来の可能性と目標
pgtestdb でも同様の「再利用アプローチ」を適用可能です:
- 現状:100ms でテスト用 DB を初期化(十分高速)。
- 大規模な場合(例:1 万個近いテストを持つ完全なアプリ開発):理想的にはセットアップ時間を10ms 程度まで短縮したいです。
- 目標:再利用を導入することで 10–20ms を達成し、テストトランザクションに近いパフォーマンスレベルを実現します。