Hatena::Grouppostgresql

PostgreSQL 雑記 このページをアンテナに追加 RSSフィード

2010-05-22PGCon 2010 カンファレンス2日目 このエントリーを含むブックマーク このエントリーのブックマークコメント

カンファレンス2日目、最終日です。

追記: Oleg 氏の撮った写真はこちら。そういえば今回って全体写真撮りませんでしたね? オークションが長引いて忘れていた?

PgMQ - Embedding messaging in PostgreSQL

PostgreSQL上に構築された Message Queue ということですが、どちらかというとさらにこの MQ を使ったレプリケーションについての話でした。トリガベースなので既存の Slony, Londiste, Bucardo なんかと同じ方式です。なんでみんな自作するのが好きなんだろう…。ただ、PgMQ 自体は一般的なメッセージングのプロトコルを話せるらしいので、キュー単体でも使い道はあるのかもしれません。

また、レプリケーションに使う際はキューへの登録をなるべく効率よくするために "ON COMMIT" トリガを利用しているようです。そのために CREATE CONSTRAINT TRIGGER をこっそり使っているとのことですが、他の DEFERRABLE 制約があると期待通りの動作にはならないなど、非公式な裏ワザなのが気にかかります。

Replication Panel

準備してないにもほどがあるパネルセッションですが、とりあえず各種レプリケーション製品 (Londiste, Slony, pgpool, Streaming Replication, Bucardo...) の開発者を演題に並べて、聴講者からのその場の質問に順番に答えていく形でした。

役に立ちそうな情報としては、各製品の最大サーバ数でしょうか。pgpool は3台、Slony は5-6台、それ以外は20台くらいを上限と考えるのが良いとのこと。ただ、多くの製品はカスケード構成ができるので、レプリケーションのグループを分割すれば、もちろんもっと多くの台数の構成もできます。

Greg Smith の性能プロファイラ

講演では無いんですが、休憩時間に Greg が寄ってきて、ものすごい勢いでまくし立てられました。全部を聞き取れたわけではないんですが、認識率×発話量 の積が大きい関係で、なぜかある程度会話が成り立つという不思議。

「俺ら作りたいものが被ることが多いから情報交換しようぜ」から始まり、彼はクエリよりももう一段階細かいレベルでプロファイリングをしたいと語ってくれました。たぶん、自分が昔手を出していたサンプリング・プロファイラを踏まえてのことなのでしょう。元Oracle DBAに話を聞くと、Postgresに移った際にチューニングの指標になる情報が無くなってしまうのは痛いらしいです。DTrace は Windows で動かないから、やっぱりDB組み込みの性能プロファイラを作りたいぞ、という話でした。

Using Git to work with PostgreSQL

PostgreSQLのコードの管理を CVS から git に移行するという、中の人にしか関係の無い話題です。git のメリットは大きいことはわかっているので、Build Farm での自動試験環境を git に対応させて移行したいということでした。その他、git の使い方の解説で、自分も以前から迷っていた、複数のブランチ (HEAD, 8.4, 8.3, ...) を並行で扱うケースが取り上げられました。一工夫要るらしく、毎回 checkout で切り替えるのでなければ、--bare でクローンしておき、そこからコピーするのが良いらしいです。

その他に、自分のレポジトリで作業した後、最後に本線にマージする場合には git merge --squash して、コミット履歴をひとまとめの「機能」として公開するのが良いそうです。


2日間まるごとPostgreSQLのみという濃ゆいプログラム編成にもかかわらず、多くの開発者 / ユーザが参加したカンファレンスでした。開発者同士やコアなユーザ同士の情報交換の場としてもとても役立っていると思います。一方、もう少し別の層のユーザを巻き込むための場もあっても良いのかもしれません。ウェブ・フレームワークとの連携や、若い学生に研究用の素材として紹介するような集まりもあると、PostgreSQLの裾野が広がっていくんじゃないでしょうか。

おまけ : 「ぽすとぐれすきゅーえる」なんて発音している人はほとんどいませんでした。みんな「ぽすとぐれす」。いまだに正式名称を "Postgres" にしないかという議論も燻ぶってはいるようです。

interdbinterdb2010/05/22 03:58お疲れさまです。
SRはカスケードできましたっけ?

pgsqlpgsql2010/05/22 06:02SRのカスケードは、2段目以降はSRではなくpg_standbyを使うことになるのでは。
ただ、特にサーバ台数に上限は無いはずなので、カスケードは不要かもしれません。

interdbinterdb2010/05/22 11:36ありがとうございます。

>SRのカスケードは、2段目以降はSRではなくpg_standbyを使うことになるのでは。

SRのソース眺めて「カスケードは無理」だと思ったので。

>ただ、特にサーバ台数に上限は無いはずなので、カスケードは不要かもしれません。

SRの制限ではないですが、walsenderプロセスはsuperuserじゃない権限で起動するので、既に(max_connections-superuser_reserved_connections)の接続があると、スレーブは追加できないないですね。
WEBサーバあたりがコネクションプールでがっつり接続して、スレーブの起動がWEBサーバの後だったりすると「レプリケーションしない!」と焦るかも、など考えてました。
せっかくオンラインでスレーブ追加できるのだから、SRの接続数もリザーブされていると名実ともに制限なしと思いますけども。

pgsqlpgsql2010/05/22 18:28個人的には、リザーブよりは、max_wal_senderを取っ払うほうが理想の設計だと思います。接続数はシェアしてくれて良いので、接続数の上限までWAL Senderに「転用」できるというイメージです。

pgsqlpgsql2010/05/22 19:03あと、単にリザーブしたいならば、WEBサーバ用の接続数を「ユーザごとの接続数上限」パラメータで絞ることで、今でもそれっぽい動作は可能だと思いますよ。

interdbinterdb2010/05/23 02:34長く書きすぎました、6/19のセミナーでお話聞かせてください。
気を付けて帰国してください。