[postgresql]PostgreSQL Conference 2012-02-24 at 品川¶
午前中、ustで流れていた部分の生ログです。残念ながらちょっと遅れてしまったので、基調講演の最初の方は取れていません。
基調講演 by Philippe BEAUDOIN, @ Bull.net¶
CNAF PostgreSQL Project
フランスの社会保障省。
11ミリオンの家族と30ミリオンの人
11億€
フランス全土に123 CAF(Local organization)
以前¶
cobolのメインフレームからPostgreSQLに移行した。
全部で18ヶ月、準備に9ヶ月。
(snip)...
migration¶
一番大きいDBが250GB。migrateとチェックを合わせて24時間以内にできた。 全部で4TB。
test¶
unit testが重かったが、受け入れテストのほうが重かった。
バッチを一ヶ月連続で動かした。毎日シーケンスを動かした。 一日のトランザクションを記録しておいて、複数回再実行した。 結果が同じかどうか確認した。
PostgreSQL instance¶
各CAFの中に、168のDBがある。10個のパーティションに分けた。
メモリ使用関連、特にキャッシュバッファの設定が一番難しかった。 キャッシュバッファの使い方のモデルを作った。
管理ツール¶
168個とDBが多い。ツールを使って管理した。
開発者はpgAdminを使っている。テスターとサポートはphpPgAdminを使ってい る。
phpPgAdminは各DBにアクセスするための一意なアクセスポイントをwebサーバを 使って提供出来るところがいいところ。DBの管理が楽になる。
保存はpgdumpは使っていない。legato networkerというソフトを使っている。 毎月indexの再生成のために、clusterというコマンドを動かしている。
SQL関連のqueryはpsqlのシートにあって、そのSQLを自動的に呼び出している。
Monitoringはnagios(check_progress.pl)。CAFとつなぐDBSP linkの監視にも nagiosを使っている。
Batch Chains¶
可用性¶
ミラーを毎日作ってる。バッチになにか問題あれば、postgresのインスタンス を一時止めて前日のデータを使う。
ミラーは二つある。２つ目のミラーはDisaster Backup Centerにある。
性能¶
以前のDBよりpgsqlは効率的だった。
既存システムとpgsqlのパーティション間を繋げるのにコストがかかる。つまり、 ユーザ的にはコネクションの処理時間が少し上がった。
バッチの処理時間が結構下がった。一方、いくつかの大きなプログラムのバッ チは時間がかかるようになった。これは、並行runで解決した。
各CAFの中で使っているSQLは簡単。joinもなく、ほぼ一つのテーブルだけ。だ いたい1日で10億query。最も負荷が高い時は、 33000 query/sec 参照されてるデータはほとんど大きくないが、queryが多いのが大変。
移行の際のアドバイス¶
プロトタイプを作ること。リスクを減らせる
プロジェクト管理の技術を使うこと
PostgreSQLのインフラ設定を注意深くすること
移行はアプリ本体だけでなく、外部ツールに対しても影響があるので注意
テストテストテスト
顧客の感想¶
すべての関係者はPostgreSQLに感謝している
プロジェクトは時間通りに進んだ
PostgreSQLそのものの問題は 0 だった
現在進行中の課題 * ハードウェアの更新 (WALのアーカイブ...) * 今は8.4だけど、今PostgreSQL 9.0に移行中
CAFは毎月3億のユーロの支払いを行なっている。これにPostgreSQLが使われている
Q and A¶
Q: なぜPostgreSQLを選んだか * :A: 発表すると、一つ目の質問はいつもこれだ。いい質問です。bullから提:案された。bullは以前のDBシステムにも絡んでいて、Oracleとpgsqlに 移行が可能だった。で、顧客は以前oracleを使ったことがあってあんま りよくなかった。 提案段階で、顧客からのテストにも耐えた
Q: 多くの人が関係したが、彼らはpostgresに習熟していたのか、教育はどう やったのか * A: 顧客はPostgreSQLを結構分かっていた。だからあまりトレーニングはし なかった。
Q: スライド17ページ。クローン1と2の同期方式は？バッチだと思うが。 * A: EMSという会社が作ったTime Finderというプログラムを使った。 変更は特に必要なかった。 * Q: ハードウェア技術でのクローニング？ * A: はい。ハードウェア的なクローニング。PostgreSQLからは透過的。 リカバリ時にはPostgreSQLの再起動が必要。PostgreSQLからはディスクの クラッシュに見える。
Q: プロジェクト期間中どれぐらいのエンジニアが働いていたのか * A: 18ヶ月100%で働いていたのは8人か10人ぐらい。 * Q: 少ないので驚いているが、それで動いたんですね。とても印象的です。
<hr>
PostgreSQL 9.2の概要 by Robert Haas @ enterprisedb.com¶
9.2 opens New Horizons¶
スケーラビリティが肝。
high-endサーバー
より大規模なデータセット
PostgrSQLのより多くのコピー
より多くのレプリカ
9.2の目玉機能¶
スケーラビリティ * たくさんのCPUを持つサーバ向け
index only scan * 大きなデータセット向け
省消費電力 * ホスティング会社向け
新しいバックアップとレプリカのオプション * スケールアウト向け
Scalability¶
CPUが多ければもっと大量のトランザクションをこなせる。
9.1まではロックがあるため8コアぐらいまでしか性能が出なかった。
9.2では32コアまで増やせる。
9月に取ったグラフを見ると、最新のバージョンだと fast lockのパッチを入れ た時点よりもっと性能が向上している。Read Onlyで32コアのマシン。32クライ アントでも225000 query/sec出ている。その後、80clientでも性能劣化が少な い。
pgdump -S、scale factor 100、32コア、AMD opteron 6128、max_connections = 100、shared_buffer = 8GB。
write scalabilityも、9.1より32、48クライアントでも性能が向上している。
スケーラビリティの向上¶
いくつものパッチによって向上している。
"Fast path"ロック。仮想transaction lockと"weak" relation lockが衝突す ることはほとんどない。だからメインのロック管理をバイパスできる
MBCC スナップショットを取るときのクリティカルセクションを短くした。多 くアクセスされるデータは別の配列に分割しすることでキャシュライン passingを減らすことで、短く出来た
WAL書き出しのスケーラビリティを向上した。複数のバックエンドがWALを書 きだそうとする時にロックをするが、それを減らした。グループコミットの 性能を改善した。TPSで5倍以上改善した。
並行WAL書き出し。複数のバックエンドがWALストリームに並列で書き込める 現実のアプリは非同期に書き込むので、これによって性能が向上できる。
ほかにもさまざまな改善をしているよ。
Index-Only Scan¶
9.1まではすべてのindex accessはどのタプルが見えるかどうかをチェックする ために、テーブルをアクセスする必要があった。キャッシュの中にテーブルと indexの両方が入っていないとパフォーマンスが落ちてしまっていた。
9.2では、必要なカラムにindexが貼ってあってタプルが"ALL VISIBLE"であれば、 テーブルアクセスを省ける。多くのケースで、indexだけでqueryを返してテー ブルにアクセスする必要がなくなる。
これを実現するために、"visibility map"と呼ばれる8.4からあった構造をデー タベース破損に対して安全にする必要があった。
index only scanはoracleとmysqlでは、かなり前から用意されている機能。今 回PostgreSQLに入ったのは喜ばしい。
省消費電力¶
herokuとかは、何十万ものpgsqlを展開している。そうなると、消費電力が問題 となる。
アイドル状態になっている時に消費電力に効くのが、1秒間に起きている auxiliary processの数。
postgres9.1では11.5 auxiliary process wake-ups/sec。
9.2開発版では、だいたい7.5 auxiliary process wakeups/secとなった。これ からもうちょっと減らす。
ホスティングプロバイダはこれでwakeups transactionを減らせるので、お金 がかからなくなる。
新しいバックアップとレプリカのオプション¶
バックアップを広範囲に広げられる。
カスケードレプリケーション
Base Backup from Standby(via pg_basebackup)
pg_receivexlog
新しい同期レプリカモード: Remote Write
他の機能¶
JSON data type
Range Type * PostgreSQLだけの機能。一定のデータに対してより良いモデリングが可能 になる。特に一時的なデータに対して有効
Parameterized Paths * plannerの改善。planとqueryの種類をもっと持てる
Faster sorting
Security Barrier Views * もっと強固に
Rewrite-Free ALTER TABLE .. ALTER TYPE * テーブルを書き換えることなく変更できる
で、次は？¶
バッファの置き換えがシングルスレッドだよね
Full page writes cause severe throughtput degradation following a checkpoint * でも、スライドを作った後に、設定をチューニングするとかなり改善でき た。これも共有する必要あるね。
チェックポイントがI/Oのストールを引き起こすよね
いくつかのロックはまだある。特に32コア以上の場合。
Q and A¶
Q: スケーラビリティについて。32コアまでなのはなぜか * A: 持ってるテスト環境が32コアだから。64コア頂戴よ。 * Q: 64コアのマシンあるから、global につなげられればテストしてくれる？ * A: www
Q: スケーラビリティについて。NUMAでメモリのローカリティとペナルティ があってなかなか向上しないと思うが。 * A: HPのiteniumのマシンを使って計測しているが、メモリアクセスのレイ テンシーに対して大きな影響があるとは思っていない。 スピンロックの方がx64マシンの方がひどいことに気がついた。でも、 NUMAかどうかは分からない。
Q: Read Scalabilityのグラフ。クライアントが20-32までの時にTPSがすごい 急に増えているのはなぜか * A: 知らねwwwwww
Q: 省消費電力。wakeupの数が減ったとあるが、どれぐらい実際の消費電力 に影響があったか分かる？ * A: おれが知ってる消費電力の測定方法はwakeupの数を測ること。 ボルトとかワットとかはハードウェアに依存してるので有効じゃない。 wakeupを減らすとsafe modeになかなか入らないということがなくなるの で、消費電力に影響する。
Q: JSONデータタイプ。今はplainなrowとかarray typeだが、将来的にarray in とかそういう機能を作る予定があるか * A: 自分もより拡張していきたいと考えているが、PostgreSQLには他にも多 くの問題があるので優先順位をどうつけるかが問題。マネージャがどれを 評価してくれるかな。
Q: write scalability。これはsync commitがoffの場合？ * A: Yes。測定環境のディスクサブシステムを管理出来なかったから。 十分にメモリがあればsync comitをonをしてもいいとは思う。そういうマ シン欲しいな～。
Q: 9.2でsync commitがonの時に性能が上がるか？ * A: sync commit onでもWAL書き込みの改善があるから、多くの性能向上が 見込める。
Q: write scalability。SSDを使うのが今流行り。SSDに特化するという開発 を進めていくことはるか？ * A: 全然 * Q: なんでよ * A: 確かにSSDはHDDと違う特性はあるが、基本的には大して変わらない。 技術的にはどちらにも効くということも多いので、SSDに特化する必要は ない。もちろん、今後SSDだけに特に効く最適化をすることはあるが、今 のところ特別な最適な方法というのは見つかっていない
Q: SSDの使い方についてコメントがある。SSDはHDDより、ランダムアクセス が非常に速い。シーケンシャルアクセスはHDDの方がちょっと速い。だから、 テーブルやindexなどのデータファイルをSSDに保存し、WALをHDDに置いたほ うがいいんじゃないか。 seqとrandomの割合によって、クライテリアを変えていくとか。 そういった小さな努力だけど、積み重ねていくと改善できるのでは。 * A: このプレゼンの範囲を超えているね。 基本的にその提案には賛成。でも、いろいろな要素がからみ合っている。 総合的に考えていく必要がある。
Q: 9.1だとstreaming replicationではスレーブではレプリケーションできな かったが、cascadeだと出来る？何段まで? * A: 今はちょっと分からない。
Q: 9.2はいつごろリリース？ * A: それはいつも待ってみないと分からない。でも、9.0と9.1は9月にリリー スされた。9.2もそれぐらいのタイミングで出せればなぁと思っている。 でも、開発者はボランティアなので強制することはできない。
Comments
comments powered by Disqus