ハクソク

世界を動かす技術を、日本語で。

Show HN: PgDog – 拡張なしでシャード化したPostgres

364日前原文(github.com)

概要

PgDog は、Rust製の PostgreSQL向けトランザクションプーラー兼論理レプリケーションマネージャ。 シャーディング や 負荷分散、 論理レプリケーション など、スケーラブルな運用に最適。 KubernetesやDockerでの 迅速な導入 が可能で、数十万コネクションを効率的に管理。 PgCat の後継として設計され、 クロスシャードクエリ や柔軟な設定を実現。 オープンソース かつAGPL v3ライセンスで、内部利用やカスタマイズも自由。

PgDog概要と特徴

  • PgDog は、 トランザクションプール と 論理レプリケーション管理 を兼ね備えた PostgreSQL用プロキシ。
  • Rust製 であり、高速かつ安全なネットワークプロキシを実現。
  • 数百DB・数十万コネクション の管理が可能なスケーラビリティ。
  • シャーディング をサポートし、クエリ内容に応じて自動的に最適なシャードにルーティング。
  • クロスシャードクエリ や 分散COPY にも対応。

導入方法

  • Kubernetes
    • Helmチャート が公式GitHubで提供。
    • git clone https://github.com/pgdogdev/helm cd helm helm install -f values.yaml pgdog ./
  • Docker
    • Docker Compose で手軽にテスト可能。
    • docker-compose upでビルドと起動が完了。
    • 起動後は psql 等で-h 127.0.0.1 -p 6432 -U postgresで接続。
  • ローカル実行
    • Rustコンパイラ をインストールし、cargo build --releaseでビルド。
    • 設定ファイル（pgdog.toml, users.toml）を用意し、cargo run --releaseで起動。

シャーディングと分散処理

  • シャーディング
    • クエリからシャーディングキーを抽出し、自動で適切なシャードへルーティング。
    • 複数シャードへのクエリ発行や、結果のメモリ内集約・返却も自動化。
  • 分散COPY
    • CSVパーサ 内蔵で、COPYコマンドを各シャードに自動分割。
    • 事前のデータ整形不要で、シャーディング済みDBへの高速データ投入が可能。
  • 論理レプリケーション
    • PostgreSQL論理レプリケーションプロトコル を理解し、バックグラウンドでデータ分割。
    • 本番稼働中でもダウンタイムなしでシャード追加やDB拡張が可能。

負荷分散と高可用性

  • アプリ層（OSI Layer 7）ロードバランサ として機能。
  • ラウンドロビン・ランダム・最小アクティブ接続数 等の戦略を選択可能。
  • SELECT はレプリカ、書き込みはプライマリへ自動振り分け。
  • ヘルスチェック で障害発生時は自動的に対象DBを切り離し、可用性を維持。
  • PgBouncerスタイル管理DB と OpenMetricsエンドポイント を提供し、Datadog等で監視可能。

設定と柔軟性

  • 設定ファイル（pgdog.toml, users.toml） で柔軟な運用が可能。
  • 多くの設定は ランタイムで即時反映、再起動不要。
  • PgBouncerやPgCat利用経験者には馴染みやすい設計。
  • サンプル設定やシャーディング用設定例もリポジトリに同梱。

PgCat・Citusとの比較

  • PgCat の後継で、 完全非同期・マルチスレッド 設計。
  • Citus はPostgres拡張として動作、PgDogは 外部プロキシ としてどこでも展開可能。
  • クロスシャードクエリ ・ 分散集約 ・ ORDER BY 等、実用的なOLTP機能を優先。
  • Citusより成熟度は劣るが、 パフォーマンス や 柔軟性 で優位性あり。

パフォーマンスとアーキテクチャ

  • Rust＋Tokio による高速・低レイテンシ設計。
  • メモリアロケーション最小化 で、PgCat比3～5%高速化。
  • pg_query でPostgreSQLの全クエリを正確に解析・ルーティング。
  • マルチスレッド で数千～数百万接続にも対応。

今後のロードマップ・貢献

  • 論理レプリケーションによる(再)シャーディング や クエリブロック・書き換え などを計画。
  • マルチテナント運用 や 不正クエリの制御 も視野。
  • オープン開発 を推進し、ユーザーの要望を積極的に取り入れ。
  • AGPL v3ライセンス で、内部利用・カスタマイズも自由。
  • コントリビューションガイドラインを遵守し、開発参加歓迎。

まとめ

  • PgDog は、 PostgreSQLのスケーラビリティ課題を解決 するための新世代プロキシ。
  • 高性能・高可用性・柔軟性 に優れた設計で、クラウド含む多様な環境で活用可能。
  • シャーディング・分散処理・論理レプリケーション をシンプルに導入・運用。
  • オープンソースコミュニティ でのフィードバック・貢献を歓迎。

Hackerたちの意見

これ、めっちゃすごいね！ローンチおめでとう！

└

ありがとう！何年もかかったよ。

PgDogにはずっと注目してたけど、すごいものみたいだね。ローンチおめでとう、Lev！これからも頑張ってね！

└

ありがとう！頑張るよ。15年の旅が始まるね。

Postgresのスケーリングに必要な革新だね。ローンチおめでとう！

とても興味深いね。こういうプロジェクトでのキーポイントは、いつも分散クエリの扱いだと思う。pgDogがネットワーク層で透明性や互換性を保とうとしてるのはワクワクするよ。もちろん、ドキュメントに書かれてる制限は予想通りで、トレードオフが必要になるだろうね。どうやってこれを扱うのか、すごく気になるな。もしこのトピックについての議論が続いてるなら、ぜひフォローしたいし、アイデアもシェアしたいな。頑張って！

└

ぜひ、Discordに参加してね！: https://discord.com/invite/CcBZkjSJdd

これすごいけど、pgdogは高可用性シナリオ（複数のフロントエンドプロキシ）を扱う予定はあるの？合意形成やスプリットブレインの問題がもっと難しくなるのは知ってるけど。もしそうじゃないなら、ダウンタイムなしで再起動を可能にするアプローチはどうなるの？（例えば、ノードがクラッシュした場合とか）

└

設定駆動だから、スプリットブレインの心配はなし。全てのプロキシが同じ設定を持ってて、デプロイも同期されるんだ。1. トラフィックを一時停止 2. 設定をリロード 3. トラフィックを再開 これが1秒以内でできるよ。ダウンタイムなしでの再起動は、ブルー/グリーンデプロイとTCPロードバランサーかDNSを使えば対応できる。

ここ数年で見た中で、一番面白いPostgresプロジェクトだな。提示されたベンチマークは標準的なプーリングにしか対応してないみたいだけど、クエリのパースやクロスシャードジョインが入ってきたらどうなるのか見てみたい。

└

ありがとう！いいフィードバックだね。クエリパーサーはキャッシュされてるから、プリペアドステートメントやプレースホルダー付きの拡張プロトコルを使ってるなら、ほぼコストはかからないよ：ミューテックスのコスト + ハッシュルックアップ。クロスシャードジョインは面白くなりそうだね。最適でないクエリを良いジョインフィルターなしで実行するのが一番のコストになると思う。正しい結果を計算するにはそれが必要なこともあるしね。また、結果セットがかなり大きくなる可能性があるから、ディスクにページングする必要があるかも。まずはOLTPのユースケースに集中して、ジョインはできるだけ下に押し込むつもりだよ。クロスシャードジョインはその後すぐにリクエストされると思う。

本当にすごいことだね！とても興味深いし、よくやった！自分のシャーディングがそんなに透明に扱われるのはちょっと嫌かも。まず、シャーディングはテナンシーの境界にあることが多いから、そこを壊すのには摩擦が欲しい。次に、シャード間のジョインの影響は、シャード内とは同じじゃないから（パフォーマンス、メモリ、CPU）、それも明示したい。とはいえ、このプロジェクトには何のマイナスもないし、本当に素晴らしいことだと思うし、たくさんのユースケースがあるよ！

└

ありがとう！ちょっと気になるんだけど：>「その境界を壊すのに摩擦が欲しい」なんで摩擦が欲しいの？ >「シャード間のジョインの影響は同じじゃない」それは普通によく理解されてて、リアルタイムのメトリクスで追跡できるよね。結局、両方とも必要だし、アプリのコードでジョインするような代替案はあんまり良くないよ。

テナントシャーディングにハッシュアルゴリズムを使い続けるつもりなの？それとも大きなテナントをシャード間で移動させるために、もっと細かい制御を許可するつもり？ホットシャードの管理はそれ自体が仕事になるし、運用の複雑さが増すよ。

└

他のアルゴリズムも考えてるんだ、例えばレンジベースとか。ホットシャード用にアルゴリズムをオーバーライドするのは全然できるよ。理想的には、Postgresがパーティションでやってることに合わせたい：レンジ、ハッシュ、リスト。そうすれば、Postgres内（例えばpostgres_fdwで）でもプロキシでもシャーディングできる。まずは問題を早くキャッチするために、できるだけ多くのモニタリングを追加するのが第一歩だと思う。シャーディングを始める前に、シャーディングキーを選んだ場合にトラフィックが均等に分かれるかどうかを確認するためのドライランモード[1]もあるよ。 [1] https://pgdog.dev/blog/sharding-a-real-rails-app#dry-run-mod...

いい感じだね、ドキュメントで最初に探すのは：ユニークインデックス 現在はサポートされてない。全てのシャードでのユニーク性を検証するために、クエリの書き換えと別の実行エンジンが必要。だけど、まだ期待できそうだね。

└

小さな慰めとして、ユニークなプライマリーキーを生成できるのがいいところだね。https://docs.pgdog.dev/features/sharding/primary-keys/。クロスシャードのユニークインデックスを実装したいんだけど、毎回のクエリでチェックするのが高コストなんだよね。アイデアがあれば教えて！

やあ、Lev！今、40TBのPostgresデータベースのシャーディングにPgDogを調べてるところなんだ。自分たちで何か作るのと比べてね。これはコラボするいい機会かも。私たちが必要としているのは、PostgreSQL用のVitessみたいなものなんだ。スキャッター・ギャザーの機能は素晴らしいけど、実際に必要なのはetcdみたいなものでの設定管理、シャードの分割、全シャードでのスキーマ変更のためのベストエフォートトランザクションとかなんだよね。全然関係ないけど、pg_query.rsを使ってクエリを書き換えるのはうまくいった？もしかしたらpg_query.rsの動作を誤解してるかもしれないけど、ASTを再構築するのは大変そうだよね。ASTのタイプが可変性や深いクローンをあまりサポートしてないから。結局、可変性をサポートするVisitorsを使ったsqlparserクレートを使ったよ。影のテーブルと論理レプリケーションを使ってPGのオンラインスキーマ変更を作るサイドプロジェクトに取り組んでるんだ。

└

やあ、Jake！コラボできるのは嬉しいな。メールしてね：lev@pgdog.dev。設定管理は解決済みの問題だよ。K8sやいろんなCDツールを使えるし、PgDogの設定リロードも同期できるよ。シャード間のスキーマ変更のためのベストエフォートトランザクションは今も機能してる。理想的には、スキーマ変更は冪等性があるから、失敗した場合でも安全に再試行できるんだ。そうじゃなければ、2フェーズコミットを試すこともできるよ。ただ、コミットされてない状態にしないように管理が必要だけど（それがバキュームをブロックするからね）。シャードの分割は論理レプリケーションでできるよ。Instacartで10TB以上のデータベースでやったことがあるから。あの規模だと、レプリケーションスロットを開けた状態でスナップショットを取り、Nインスタンスに復元して、シャード番号に合わないデータを削除して、論理レプリケーションで再同期する必要があるんだ。もう一つ試してみたいのは、Pg 17のストリーミングレプリカからの論理レプリケーションを使うこと。プライマリに影響を与えずに、16のレプリカで再シャーディングを並列化できる気がするんだ。その場合、postgres_fdwやPgDogを使って外部テーブルを通じてテーブルをCOPYするのが実現可能かもしれない。考慮すべきことだね。pg_query.rsは今は可変性があるみたいだし、私も新しいクエリを書き換えたり生成したりしてるよ。100% Postgresパーサーなのがすごく重要だね。「deparse」メソッド（構造体 -> SQL）がほとんどすべてのNodeEnumにあるから、もっと複雑なことをするのにも良さそうだよ。