PgDay 2012

ということで今年もPgDay 2012 Japan | 日本PostgreSQLユーザ会に行ってきました。
今回は面倒なんでツイートまとめ＋αで。
＃講演タイトルは正確なものではありません・・・。

The PostgreSQL community

  • Magnus氏の講演。逐次翻訳つき。
  • PostgreSQLの特異性。所持している企業がない、開発をコントロールする企業もない。多くの企業、個人が協力して開発を進めている。
    • プロダクトそのものよりもコミュニティのほうがある意味重要。
  • Core Team(6名)。運営委員会のようなもの。Core Teamの役割としては技術的な決定や開発は行わない。
    • もちろん、Core Teamのメンバが個人として開発、決定をすることがある、
  • Commiter(15-20名)はコードの門番。Commiterの承認がなければソースは取り込まれない。gitにpushできる権限を持つ。コードの機能を満たしている、バグが無い、ドキュメント、コメント等を勘案してコードを判断する。
  • Linuxのようなsubsystem commiterはいない。分野の専門性に差はあれそれで役割を分けるわけではない。
  • DevelopersとCode contributors。人数は不明。おそらく最低200人はいるだろう。
  • Coders. コードの作成、他人のコードのレビュー。1つのfeatureを書いたら別の1つのfeatureのレビューをするという原則がある（大きさによっては5人くらいでレビューすることもある）
  • 他にDocumentatoin, Testing, Benchmarking, Feature design等々の役割をもった人がいる。
  • Infrastructue. 50台くらいのサーバを管理。Website, ML, Repositryなどのサービスを運営。
  • Support companies, Community Support. サポートに関わる人数は数千人はいるだろう。無償のコミュニティサポートでML, IRC, Web forumsが使える。基本は英語だが（日本語など）言語圏/地域別のコミュニティもある。
  • 商用サポートの意義。現地に赴いてサポートできる。SLAの保証。一定時間内の回答の保証。機密性の保証。ビジネスで必要な機能を開発してもらうなど。
  • コミュニティサポートと商用サポートは競争するものではなく、協調するものである。商用サポートに携わっている人間がコミュニティでも活動するのは普通。
  • 他の役割。Security, Advocacy/Press, Conferences...
  • PostgreSQL Coreの周囲。各種API、管理ツール、レプリケータなど様々なソリューションがある。こうした他のプロジェクトを含めた全体がPostgreSQLを構成している。Coreでなくても重要。
  • プロジェクトへの貢献。開発、翻訳、コミュニティ形成、マーケティングなどいろいろある。
  • 開発の貢献。最初は簡単なもの慣れているものから始めよう。まず他の人のコードを読もう。開発者MLに参加してMLを読もう。プログラムだけでなくPostgreSQLのコミュニティの進め方も学べる。パッチを書かなくても議論をフォローするだけでも役に立つ。
  • しかし書いたpatchは簡単には承認されない。リジェクトされるか別の方法を提案されるだろう。そしてコード承認のプロセスはオープンである。だからこそ、MLの議論を読むことは重要。
  • 他に重要な貢献として翻訳がある。翻訳されることでローカル言語圏での利用が広まる。13言語に翻訳されている。一番メンテナンスされているのは日本語らしい。
    • JPUGの人超偉い。
  • Core以外の機能でも翻訳することで貢献することができるはず。
  • コミュニティの構築。ユーザグループを作ろう。近隣になければ支部を作ろう。経験を共有しよう。他のユーザグループのユーザグループ（言語系など）にも参加し、PostgreSQLについて教えよう。
  • マーケティング。記事の投稿、ブログへの投稿、他DBMSを使ったプロダクトで使ってもらえるようにPostgreSQLをアピールしてほしい。
  • 自国語から英語に翻訳して発信することで、世界中の人に見てもらえる。
  • まとめ。「俺がPostgreSQLだ！」（ちょっと違う）
  • QA. コミュニティ内で意見が割れた場合どう決定しているのか？→原則は全員が納得するまで議論する（たいていは）。commiter間でどうしても決定しない場合は、coreチームで決定する。非公式ルールとして自分で働きかけている案件への意見は重視される。
  • QA.DBのユーザはアイディアはいろいろ持っている。それをどうやって開発者に伝えるか。具体的な例を紹介してもらえると嬉しい。→むしろユーザ/開発者の境界線を曖昧にするほうがいいのではないか。
    • 悪い要望の例。「他の製品にこの機能があるから、それを実現してほしい」　なるほどｗ

PostGISとRの連携

  • 背景
  • 社会統計・GISもビッグデータ化
    • 100万を超える統計情報ファイル
    • 100万を超える地図データ
  • 分析手法の多様化、メニュー操作の限界
    • 何をどう処理したのか、履歴が残らない。
  • データベースと統計処理言語の連携
  • pgAdmin3から自作プラグインでRを起動、そんなこともできるのか！
  • rgdalが動かない件。「Rの世界では良くあること」って・・・ｗ
  • 本命はRのサーバ化(Apache+PHP)
  • QA.PostGIS、PostgreSQLで使っていたデータ量。100GBくらいはあった。使い方として同時接続はないので、あまり性能面では困っていない。地理データのような大きなデータのインポートは今でも課題ではある。
  • QA. 最近Rを使い始めたが、いい開発環境はないか？ Rのコンソールを使うより任意のエディタで使うほうが多い。R Studioというのも今後は使われてくるかも。

レプリケーションによる負荷分散

  • pgpool＋PostgreSQL SR構成で、商用DBMSの同等機能と遜色のないフェイルオーバが可能。
  • pgbenchモデルでの検証。onよりremote_writeにした場合、約5%程度tpsが上昇。
  • ここでちょっとPPASの話。その中のxDB Replicationの話。xDB Reolicationではマルチマスタ構成が可能。
  • PostgreSQL9.3ではマテリアライズド・ビューが実装されるのか！？
  • QA. カスケード構成で効果があったのは実はWAL送信のNWネックになってないか？なのでスループットではなくレスポンス時間の劣化の情報も欲しかった。

PostgreSQL 9.1を商用システムに適用

  • 9.1を商用システムに適用したときの話かあ。どんな話が聞けるのか楽しみ。
  • 商用システム適用の5箇条。検証は大事、サイジング、運用とくに切り替え、問題発生時の備え、監視で安心。
  • 最後に高可用性システム構築のためのDBアプライアンス "GresCube"の説明。でも、お高いんでしょ？・・・と思ったらそうではないらしい。
  • QA.DBの監視は何を使っている？→statsinfoも使用している。あとはDBプロセスの死活監視など。

PostgreSQL-XCで高可用化

  • おお、ミカエルさん日本語でプレゼンするのか。凄い。
  • スケーラビリティ検証では10台構成で理想値に対して60%程度はスケールしている。＞Postgres-XC
  • Postgres-XCの現バージョンはPostgreSQL9.2にも追随している。
  • Postgres-XCではOIDは各ノードでそれぞれ持っている？ もしかすると、tableoidやctidを使うような全文検索系だと相性が良くないってことなのかな・・・。
  • GTMについては同期モードでバックアップをとるように対応している。 DatanodeはLog shipping、Cordinatorも(致命的にはならないが)バックアップをとるようにしている。
  • O_____R__www 言っちゃダメですよ〜
  • Server全体が落ちた場合は、データノードとコーディネータで行った両方の対応が必要ということか。
  • その後、デモ。GTM二重化、proxy4つ、、コーディネータ、データノードも二重化している。
  • Version 1.0.1は9.1ベースなので注意。Triggerはこれから。Onlineノード管理で逐次ノード増加。テーブル再編成の並列化。結合などのJOIN方式。ソートの効率化。エラー制御、特に非トランザクションコマンドのエラー処理対応など。
  • Postgres-XCの次のメジャーリリースは2013年4月予定。インストーラや統計情報収集、バックアップ・リストア等は周辺チームが開発を進めている。
  • QA. PostgreSQLバージョンアップへの追随のポリシーは？→原則、全てキャッチアップする。PGXCで条件コンパイルしている(yacc部分除く)。

pgpool-II新機能

  • 次のメインセッション。pgpool-II新機能。オンメモリクエリキャッシュが気になるので、こっちを聞くことにする。
  • 機材不調。立て直しの間に石井さんが飛び込みで、pgpoolとPostgres-XCとPostgreSQLソースとの関係について閑話。こういうのが聞けるから、やはり現地で聞くのは面白い。
  • 最後にwatchdogのデモ・・・なんだけど後ろのほうにいるから良く見えない(´・ω・｀)
  • ぬーん、質疑の時間がなくなった。石井さんが見ることを期待して此処に書こう。GRANT等でユーザのアクセスが変わった場合にも、そのユーザに関するメモリキャッシュは無効化されるのでしょうか？
    • 石井さんから回答。
    • Tatsuo Ishii @tatsuo_ishii 現状そこまでやっていません。技術的には可能だと思うので、ちょっと実装法を考えてみます。

レプリケーション構成の高可用化

  • 最後のセッションはレプリケーション構成の高可用化。チュートリアルセッションが勉強会で聞いた内容だったから・・・という消極的な理由。
  • 最後にpgsql RAに関する最近の動きの話。PM1.1の仕様変更に追随。TimelineIDのインクリメント防止のための実験的実装(PostgreSQLが一旦停まるから？)、いろいろバグ修正など。RAは最新に入れ替えたほうが良い。
  • QA. タイムラインIDインクリメントがなくなればデータコピーは不要？→なくなっても、ロックファイルがあるとデータ不整合が発生する可能性があるので、その場合コピーは必要。

LT1：なぜO/Rマッパーが重要か？

  • 分解・構築・抽象化がSQLにはない。
  • ORMを使うと分解・構築・抽象化・そして再利用をやってくれる説。
  • 面白い観点。そういう考え方でSQLを見たことはなかった。

LT2 PostgreSQL機能拡張

  • @87さんのプレゼン。
  • PostgreSQLの様々な拡張の話。
    • 関数、演算子、データ型、インデクス、組み込み言語、FDWなど
    • ksj もデータ型実装例として紹介してもらいました。

クロージング。

  • 永安さんのトーク。テーマ選定。先進的な話と基本的な話の二本立てを選んだ。
  • Magunsさんのトークはコミュニティを広く知ってもらう意図だった。