PgDog - 拡張機能なしでPostgresをシャーディングできるツール

 (github.com/pgdogdev)
4 ポイント 投稿者 GN⁺ 2025-05-29 | 1件のコメント | WhatsAppで共有
  • Rustで開発されたPostgreSQL向けのトランザクションプーラー兼論理レプリケーションマネージャーで、水平スケーリングとシャーディング自動化機能を提供
  • 拡張機能なしで手軽にPostgreSQLデータベースをシャーディングでき、数百のデータベースと数十万の接続管理に最適化
  • アプリケーション層（OSI 7）で動作するDBロードバランサーとして、SELECTはレプリカへ、それ以外はプライマリへ自動ルーティング可能
  • PgBouncerのようにトランザクション／セッションプーリングをサポートしつつ、クエリを解析してシャードへ自動ルーティングし、結果のマージまで実行
  • COPYおよびロジカルレプリケーションを使ってデータをシャードへ自動分配したり既存DBを無停止でシャーディングできる
  • 構成はTOMLファイルでシンプルに定義でき、ランタイム再構成が可能
  • Postgres拡張を利用するCitusとは異なり、DBの外部プロキシであるためRDS、Cloud SQLなどでも利用可能

プロジェクト紹介と主な価値

  • PgDogはPostgreSQLデータベースに対して、簡単なシャーディングと論理レプリケーション、トランザクションプーリング、L7負荷分散など、幅広い水平スケールを支援するオープンソースソリューション
  • Rust言語で開発されており、高性能と安全性を確保
  • PgDogは拡張機能のインストールなしに、単一のプロキシデプロイだけでシャーディング、データ分散、障害復旧、柔軟なロードバランシングを実現
  • 競合製品（例: PgBouncer、PgCatなど）と異なり、自動シャーディングと論理レプリケーションまで一通りサポートし、運用中の設定変更とリアルタイムモニタリングが可能な点が強み

主な機能

負荷分散 (Load Balancer)

  • PgDogはOSI 7層のアプリケーションレベルプロキシとして、複数のPostgreSQLレプリカ・プライマリノードにクエリを分散し、障害や負荷の集中を防止
  • 分散戦略はラウンドロビン、ランダム、最小接続数などを幅広く提供
  • クエリ種別を判別し、SELECTはレプリカ、それ以外の書き込みクエリはプライマリノードへ自動転送するよう振り分け
  • ヘルスチェックと障害発生時の自動フェイルオーバーを実行し、ネットワーク障害やハードウェア障害時にも可用性を確保

トランザクションプーリング

  • PgDogはPgBouncerのようにトランザクション／セッションプーリングによる効率的な接続リソース管理を行い、数十万のクライアントも少数のバックエンド接続でカバー可能

シャーディング

  • クエリ構文を直接解析してシャーディングキーを抽出し、最適なルーティングアルゴリズムを適用
  • 複数シャードのデータベース間でのクロスシャードクエリにも対応し、結果をメモリ上で統合して透過的にクライアントへ返却
  • COPYコマンド実行時にCSV解析によるデータのマルチシャード分配をサポートし、大規模ロードに便利
  • PostgreSQLの論理レプリケーションプロトコルをベースに無停止のバックグラウンド同期を行い、運用中でもリアルタイムでシャード追加やスケール拡張が可能

モニタリング

  • PgBouncerスタイルの管理データベースとOpenMetricsエンドポイントの両方をサポート
  • Datadogなど外部モニタリングやダッシュボードの例も提供

構成とランタイム

  • 主な環境: Kubernetes（Helmチャート提供）、Docker、ローカル環境（Rustビルド）で手軽にデプロイ・テスト可能
  • 通常は2つの設定ファイル（pgdog.toml、users.toml）を書くだけで、最小限のシャーディングおよびユーザーベースの運用環境を構成完了
  • 設定値の大半はリアルタイムで変更可能で、プロセス再起動なしに動的反映される

性能とライセンス

  • PgDogはRustとTokioベースの高性能な非同期ネットワークプロキシで、データ移動の最小化と性能低下の抑制に注力
  • ベンチマーク結果を公式ドキュメントで提供しており、性能基準の設定が可能
  • AGPL v3オープンソースライセンスを採用し、企業内利用やプライベートなカスタマイズにも広く開放
  • ただし、パブリッククラウドサービスを提供する企業はコードを改変した場合、その内容を共有する必要がある条件あり

プロジェクトの現状と貢献

  • 現在は初期段階のため、アーリーアダプターによる自主導入を推奨しており、機能ごとの安定化は継続的にアップデート中
  • 機能別のテストやベンチマークも継続的に実施
  • オープンソースコミュニティからの貢献を歓迎。詳細はContribution Guidelinesを参照

結論

  • PgDogは運用環境でPostgreSQLの水平スケーラビリティ、高可用性、自動シャーディングを必要とする開発チームや企業現場に優れたソリューションを提供
  • 別途拡張機能や複雑なインフラ構築なしでも、迅速に導入・カスタマイズできる点が大きな強み

関連記事

1件のコメント

 
GN⁺ 2025-05-29
Hacker Newsの意見

  • Levに挨拶しつつ、現在40TB規模のPostgresデータベースのシャーディングについてPgDogと自前構築を比較検討している状況を説明し、Vitess for PostgreSQLのように動作するソリューションが必要だと言及。scatter gather機能に加えて、etcdのようなものに基づく設定管理、シャード分割、全シャードへのスキーマ変更適用のためのbest-effortトランザクションなどが必要だと強調し、pg_query.rsでのクエリ書き換え経験を質問。AST型の不変性やディープクローン不足のために書き換えが難しいと感じた経験を共有し、最終的にはVisitorパターンをサポートするsqlparser crateを使っていること、そしてshadow tablesと論理レプリケーションをベースにしたPG向けオンラインスキーマ変更をサイドプロジェクトとして開発中だと語る

    • 協業提案を喜びつつ連絡先を共有。設定管理はすでにK8sや各種CDツールで解決でき、PgDogの設定リロードも同期可能だと説明。best-effortトランザクションによる全シャードのスキーマ変更はすでに動作しており、イディオムポテントなスキーマ変更が最善だが、失敗時には2フェーズコミットも検討対象だと言及。シャード分割は論理レプリケーションで可能だとし、Instacartでの10TB超の経験に触れつつ、レプリケーションスロットを開いてからNインスタンスへ復旧し、シャード番号が一致しないデータを削除して論理レプリケーションで再同期する手順を共有。Pg 17の論理レプリケーションをstreaming replicaで使って並列分割するアイデアや、外部テーブル経由で直接データをCOPYする方法も構想中だと明かす。pg_query.rsは今では可変的に動くようで、最近は実際にクエリ書き換えや生成に積極的に活用しており、100% Postgresパーサベースである点が重要な強みだと強調。「deparse」機能が各所にあり、複雑な作業もかなり可能そうだと述べる

  • Vitess for Postgresがあるなら、Yugabyteがその役割を果たすのではないかという質問

  • コア機能だけを見ると小さく見えるが、PgDogによってコード変更なしで読み取りはリードレプリカ、書き込みはプライマリへ分離できる機能は非常に大きな利点だと思う。多くのアプリはR/W分離を直接サポートしていないため、プロキシレベルで処理すると過去に大きな速度改善を得た経験があると共有し、プロジェクトを称賛

    • この機能はすでにpgcatでも利用可能だと案内し、pgcatリンクを共有

    • InstacartではMakaraを使ってR/W分離をしていたが、PythonやGoなど複数の言語環境で毎回同じことを実装するのはかなり面倒だったという経験を共有

  • プロジェクトは印象的だと評価しつつ、完全自動のシャーディングにはやや距離を感じるとコメント。一般にシャーディングはテナンシー境界で行われ、その境界を越える行為にはある程度の摩擦があってほしいと説明。クロスシャードjoinはインシャードjoinと性能・メモリ・CPUの面で異なるため、それを明確に表現してほしいという意見。ただしプロジェクト自体には疑いはなく、活用例は非常に多いだろうと述べる

    • なぜあえて摩擦を求めるのかと問い返しつつ、クロスシャードjoinの性能問題はたいてい十分理解されており、リアルタイムメトリクスで追跡可能で、結局は両方の手法が必要だと補足。アプリコード側でjoinする代替案はそれほど望ましくないとも付け加える

  • PgDogを注視しており非常に印象的だと評価。リリースを祝福し、今後の発展に期待を表明

    • 15年の旅が今ようやく始まったのだと語る

  • ネットワーク層で透明性と互換性を保ちながら分散クエリを処理する点が最大の魅力だという意見。現時点でドキュメントにある制約は当然であり、トレードオフが必要になるだろうと期待。どう解決していくのか興味があり、追加の議論があるなら参加したいと提案

    • Discordコミュニティへの参加を勧め、招待リンクを共有

  • PgDogのようなソリューションで最大の難しさは、シャーディングされた複雑なクエリを最後の1%まで正しく処理すること（あるいは異常なクエリを検出すること）、そして分離性と一貫性を完全に保証することだと言及

  • ドキュメントを見て最初にUnique Index対応の有無を確認したが、まだクエリ書き換えと別個の実行エンジンが必要なため未対応なのは残念だとフィードバック。それでも可能性が見えるので期待している

    • 小さな代償で全シャードにわたって一意なプライマリキーを生成することはすでにサポートしていると説明し、関連ドキュメントリンクを共有。クロスシャードのユニークインデックス実装は全クエリで確認が必要になるためコストが高く、アイデアはオープンにしていると述べる

  • ここ数年で見た中で最も興味深いPostgresプロジェクトだと強調。提示されているベンチマークは基本的なコネクションプーリングだけを扱っているようなので、クエリパースやクロスシャードjoinが動作するときの結果が気になるという意見

    • クエリパーサはキャッシュされるため、prepared queryやプレースホルダを使う場合はロックとハッシュ参照が追加されるだけで、ほぼコストはないと説明。クロスシャードjoinについては、フィルタが最適でないとクエリ処理コストが高くなり、結果セットが大きい場合はディスクへのページングが必要になる可能性もあると予想。まずはOLTPに注力し、可能な限りjoinをプッシュダウンしようとしており、近いうちにクロスシャードjoinの需要も大きくなるだろうと予測

  • Postgresの拡張性に不可欠な革新だという評価とともに、リリースを祝福

  • プロジェクトが非常に素晴らしく見えるとし、リリースを祝福

    • 何年にもわたる努力の成果だと強調