PgDay 2012 Japan 参加しました

11月30日に品川開催だったPgDay 2012 Japanに参加しました。

http://www.postgresql.jp/events/pgday2012_fall/

前回の
PostgreSQL Conference 2012の感触がよかったので
今回も参加させていただきました。

■基調講演　Inside the PostgreSQL community - How the product gets built

PostgreSQLのコミュニティの話。

PostgreSQLは所持している企業がなく、開発をコントロールする特定の企業もない。
個々人が協力して開発を進めており、プロダクトよりもコミュニティの方が重要。

●コミュニティ内のチーム

・Core Team（6名）
運営委員会のようなもの。
技術的な決定や開発は行わない。
ただ、Core Teamのメンバーが個人で開発をすることはある。

・Commiter（15-20名）
コードの門番の役割となる。
Commiterの承認がなければソースは取り込まれない。
ソースコードのバグが無いかコメントがあるかなどをチェックする人々。
Linuxのようなsubsystem commiterが存在しない。

・Developer、Code contributors（200名以上）
コードのレビューを実施したり、ドキュメント担当者、テストを実行する人、ベンチマーク担当、アーキテクチャを設計する人。

・Infrastructure
主にWebsite、wiki、MLなどのインフラを担当する。
世界50台のサー名を管理する人々。

・Support campanies（数千人）
サポートに関わる人は数千人はいる。
英語が基本だが、言語圏や地域別のコミュニティもある。

商用のサポートはSLAを保証する。
例えば、一定時間内の回答、機密性、追加開発 etc

●貢献について
プロジェクトへの貢献は開発、翻訳、コミュニティの形成、マーケティングなどが考えられる。
開発で貢献したい場合は、簡単で慣れているものから始めると良い。まずは他の人のコードを読んでみること。
開発者MLに参加してMLを読んで、プログラムそのものだけでなくPostgreSQLのコミュニティの進み方も学ぶことができる。パッチを書かなくても議論をフォローするだけでも役立つ。
翻訳も重要な貢献である。翻訳されることでローカル言語での利用が広まる。
現在13言語に翻訳されており、フランス語・日本語が一番メンテナンスされている。
特に日本語は素晴らしい。

コミュニティを構築したり、ユーザグループを作って、経験を共有しよう。
そして他の言語系などのグループに参加してPostgreSQLについて話そう。
マーケティング、記事投稿、ブログ投稿などを行ってPostgreSQLをアピールして欲しい。

●QA
・コミュニティ内で意見がわかれた場合の意思決定は？

原則は全員が納得いくまで議論する。たいていはこれで解決している。
それでも決定しない場合はcoreチームが決定する。
ただ、それはせいぜい年に1回あるかないか。

・DBの「ユーザ」もアイデアを持っていると思うが、開発者へ伝える方法はあるか？

ユーザと開発者の境界線を曖昧にするほうがよい。
ただ、悪い要望として「他のDB製品にこの機能があるから、これを実現してほしい」はよくない。


■PostGIS と R の連携による地理・環境データ分析

PostGISとRを連携させるやり方、デモの話。
社会統計やGIS分野もビッグデータ時代になっている。

●背景
Excelでデータを管理していたが、さすがに管理しきれなくなった。
地域別データの管理もイラストレータを用いていたが厳しくなった。

●ビッグデータ化
統計情報ファイルが100万を越える。地図データも100万を越えてしまっている。

分析手法が多様化しており、GUIツールだと操作履歴が残らないで困る。

そこでデータベースと統計処理言語を連携させることにした。
Rスクリプトで実施する。データベースは経路探索の関数が使えるPostGISを選択した。
PgAdminⅢから自作のプラグ院でRを起動できるようにした。

ただ、rgdalが動かない。
「Rの世界では良くあること」

●QA
どれくらいのデータ量があったのか？

100GB程度はあったが、同時接続はしないため性能面で困ることはなかった。
ただ、地理データのような大きなデータのインポートは課題。

Rの良いツール環境はないか？
正直使いにくい。
R studioというIDEはあるが、プロットが小さくなってしまう。
結局現状ではスクリプトとエディタで作るのが一番よい。


■進化する PostgreSQL のレプリケーション　～ 効果的な負荷分散とスムーズなデータ連携 ～

・pgpool＋PostgreSQL（ストリーミングレプリケーション）構成でフェイルオー場所用時間を測定
商用DBMSと比較しても劣らないフェイルオーバが可能。

●PostgreSQL9.2　レプリケーション検証
・synchronous_commitの違いによるプライマリサーバの性能比較
→　onとremote_writeでは後者が約5%の性能向上
User CPU使用率も5％増加しておりリソースを効率的に使われている。
スタンバイサーバのデータ損失の可能性が高くなるが、プライマリ性能を優先する場合は有効。

・カスケード構成の効果
カスケードレプリケーションはプライマリサーバの負荷軽減に有効


●Postgres Plus Adanced Sererの説明
異種DB間レプリケーション　xDB　Replication機能あり。
マルチマスターレプリケーション構成がとれる。
PostgreSQL/Postgres Plusだけではなく商用RDBMSとのデータ連携が可能。

用途に応じてレプリケーション構成を選択してください。

●PostgreSQL 9.3
マテリアライズドビューが実装予定・・らしい。

●QA
カスケード構成で効果があったのは、WAL転送のNWネックのせいではないか？
そのためスループットよりレスポンスタイムの劣化に関する情報も欲しかった。


■PostgreSQL 9.1 でつくる高可用システムにまつわるエトセトラ

NTTデータがPostgreSQL9.1を商用システムに適用した時のエピソード。

商用システム適用の5か条。
・検証が大事
・柔軟なサイジング
・運用が要　-切り替えは100%成功かつ即座-
・備えあれば憂いなし
・監視で安心

STONITHによる電源OFFに注意。
系切り替えの際に誤って新マスターを落としてしまわないようにタイムアウト時間を延長。

ホスト名に注意。
「Master」みたいなホスト名をつけるとスクリプトで誤認識するので、リソース名は変更すること。

とにかく検証が大事。
障害時検証項目は、単一部分の障害ではなく、複数個所の同時障害も想定して検証すること！


●QA
監視は何を対象にした？

・プロセス
・HAクラスタが生きているか
・統計情報が蓄積されているか


■Postgres-XC クラスタにおける高可用機能

●1台のサーバにCoodinator、DataNode、GTM、GTM Proxyが同居しても構わない。

●障害時対応
・GTM
同期モードでバックアップをとるような対応
・Datanode
Log shippingでフェイルオーバー対応
・GTM-Proxy
再起動してしまえばいい
・Coodinator
同じカタログなら他のCoodinatorが肩代わり可能
・サーバ全体が落ちた場合
DataNodeとCoodinatorの両方の対応が必要。

●現状と今後
Ver1.1はPostgreSQL9.1ベースで作成されている。
Triggerはこれから。
時期メジャーリリースは2013年4月予定。
インストーラ、統計情報収集、バックアップリストアなど。

●QA
PostgreSQLのバージョンアップに対する追従は？

原則、すべてキャッチアップしていく。


■pgpool-II で PostgreSQL の性能と信頼性を高めよう

機材故障で配布スライドを読んでいく形式になったため割愛

●機材故障中の小話
Postgres-XCはPostgreSQLのソースの良いところをうまく使っているとのこと。



■HA クラスタで PostgreSQL レプリケーション構成の高可用化

・PostgreSQL9.1からレプリケーションのモードを「非同期」「同期」で選択可能
　WALの同期を保証し、参照可能データの同期は保証しない。

・レプリケーションモードはスレーブ単位、トランザクション単位で設定可能
9.1～　syncronous_commit = localが追加
9.2～　syncronous_commit = remote_writeが追加

・Act/stnandbyとMaster/Slave
それぞれ一長一短のため、サービス要件に応じて選択すること。

・運用時の注意
TimelineIDがずれているとレプリケーションができないため注意
「Slave起動前にMasterのデータをコピー」と覚えておけばOK
→　WALアーカイブではだめ、データ全体をコピーすること


■所感
会場が220人程度参加の満員状態で、PostgreSQLの注目度の高さが伺えた。

コミュニティの話から商用エピソードの話まで聴けたので個人的には満足。
質疑応答の時間が少ないのが若干残念ではあった。

主な内容として障害対応や性能試験の話が多かったため
さすがに正常系では大きな問題はないようだ。
PostgreSQLもカスケード接続ができるようになったことから複数台構成が当たり前になってきている印象を受けた。