スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PgDay 2012 Japan

PgDay、パンとご飯の日ではなく、PostgreSQLのカンファレンスに行ってきました。

PgDay 2012 Japan_121130

もちろん業務(仕事)の一環として行っているわけですが、残念ながらチケット代は自腹です。。
世知辛いですが、交通費も自腹・・・。
交通費に関しては、定期もあって品川-大井町の一駅分だけなので、まぁ良いんですが。

カンファレンスの参加者は、切り良く?222名とのことでした。

Magnus Haganer_121130

最初は、PostgreSQL開発グループのコア・メンバーが欧州から来て、基調講演が行われました。
僕にも、OSSそのものを読み書きできるプログラミング能力と英語力があればグループに参画できると思いますが、あくまで僕は作っていただいたデータベースを利用させていただく身ですからねー。
今後も頑張っていただきたいと思います。

その次は、埼大の研究者が、PostGIS(PostgreSQLで地理空間情報を扱うためのOSS)とR(OSSの統計解析プログラミング言語)を使って、地図上に色の濃淡などで各種情報を表現できますよー、というのを実際に動かしながら話していました。
そんなの、色んな会社がサービスで提供してるじゃん、と思ったりもしましたが、それなりの技術者一人いれば、フリーでできちゃいますよー、っていう時代になってるんですよね。
僕は、そんな能力の高い技術者でもないし、地理情報そのものをチャンと扱ったことが無いので、両方とも未知の分野です。
ただ、PostGISに関しては、将来的に多少なりとも知り得ることができるかな。
ま、少しずつでも色々と自分で新たなことを身に付けていかなきゃと、改めて思ったわけで。

お昼を挟んで、負荷分散に関する各種手法の検証結果、可用性に関するネタが披露されました。
NTTデータの話は、自社の営業っぽい感じがして、チョット眠たくなりました。

その後は、PostgreSQLそのもののテクニカルな講演を3つ聴きました。
こちらは、今後PostgreSQLを利用する際には、多少なりとも役立つかなと。

ところで、根本的なトコで気になっているところがあります。
PostgreSQLの特徴である追記型のデータ格納方式ですが、コレって今後も思想を変えないんでしょうか?
10年ぐらい前であれば、ハードウェア・スペックを考慮すると、そういう考えもアリかなって思えたけど、今はイマイチな印象しか受けません。
Autovacuumがあると言えども、全レコードを更新してしまうと、一時的に容量が倍になるわけですよね?
参照専用であれば気にせずに済むけど、ごく普通の更新も発生するシステムでは、やはり導入を躊躇させる要因になっている気がします。
関連記事
スポンサーサイト

この記事へのコメント

- nanashi - 2012年12月02日 10:50:43

こんにちは。

追記型について。確かに1トランザクションで全データを更新すると、一時的に容量が増える場合もありますが、1トランザクションに限っていえば追記型だけでなく、ロールバックセグメント方式のMVCCも同じ結果になります。つまりMVCCを使う宿命であって、追記型MVCCだけの欠点ではありません。

また、Postgresの追記型の後始末機能であるVACUUMは、バージョン毎に工夫がなされていて、ご指摘のAUTOVACUUMもそうですが、HOTと共に導入されたガベージコレクション(スキャン時にVACUUMもどきの動作を行う)などかなり進化していて、今や追記型の利点のほうが勝っている状態といえます。
たとえば大量データのアボートは速いです。一般論としてロールバック型はこれが遅いですね。

- あんま覚えてへんわ - 2012年12月02日 22:29:33

nanashi さん

コメント、ありがとうございます。

これまでOracleを利用してシステムを構築してきている身として、オブジェクトそのものの領域が無駄に拡張されて汚れる(物理的【ストレージ】には、RAIDや仮想化を使ってることが多いから、あくまで論理的な話ではありますが)ことに、ちと違和感があるんですよね。。

参照専用DBとしてPostgreSQLを使ったことがある程度で、現時点ではPostgreSQLのチャンとした知識を持ち合わせておりません。
近々、更新がメインになるシステムでPostgreSQLを利用するかも、ということだったので、今回のカンファレンスに参加しました。
(結果的に、Oracle11gで構築することになってしまいましたが…)

ただ、近い将来にはPostgreSQLを使って更新系システムを作る可能性は十分にありますので、チャンとした知識を身に付けて、nanashi さんに教えていただいた内部動作なぞを知って、パフォーマンスの良いDBを構築できるようにしたいと思います。

- nanashi - 2012年12月04日 01:22:45

MVCCで古いバージョンが残ってるという話ですよね。不要になったデータはVACUUMという処理で削除していくわけですが、VACUUMの処理性能がとてつもなく向上したので、汚れるという感じはないです。かなり頻繁にCleanUpしてくれます。なので無駄なデータ領域の拡張ということはまずありません。
少し詳しく書くと、1トランザクションで全テーブルを全更新的なすごいことをやっても、他のトランザクションが古いデータを参照していなければ、ほぼすぐに古いデータは消されます(8Kのブロック単位でCleanUpされます)。
テーブルの更新を続けても、かなり頻繁にブロック単位でCleanUpがなされるので、データ領域がふくれあがることはまずないです。CelanUpされたブロックの空いている領域にデータを追記していくので。(古いデータを参照しているトランザクションが残っていれば消えませんが、それは仕方が無い。ロールバックセグメント方式でも同じ)
8kのブロックレベルで空き領域を再利用していくので、論理的にも物理的にも汚れるというイメージは持った事がないです、個人的には。

ちなみに、Oracleのテーブルスペースって拡大したらしっぱなしですけど、PostgresならVACUUM FULLでデータ領域が適正な大きさ(不要なデータがない状態)に戻るので、運用はかなり楽ですよ。
巨大データのテストをやったあと、データを消してもテーブルスペースは小さくならないじゃないですか、OracleとかMySQLとか。欠点だったVACUUMが今や長所の一つという人もいます。

- あんま覚えてへんわ - 2012年12月06日 00:20:54

nanashi さん

1トランザクションで全テーブルを全更新的なことをやった場合、コミットorロールバックするまでは、古いデータを消すことはないのではないでしょうか?
消してしまうと、ロールバックできなくなっちゃいますし・・・。

結局は、全更新をすると一時的には容量が倍になる、という認識なのですが、VACUUMにはそうならないような仕掛けがあるんでしょうか?

数年前と比べて、VACUUMのパフォーマンスがかなり向上しているんですか。
参照専用でしかPostgreSQLを使ったことが無いため、Autovacuumの性能なども実感していないのですが、メモリ・パラメータの設定等をシッカリしておけば、今は十分に更新系システムに耐えられる、ということですね。

プロフィール

あんま覚えてへんわ


「あんま覚えてへんわ」です。

最新記事
最新コメント
月別アーカイブ
カテゴリ

openclose

カレンダー
10 | 2017/11 | 12
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -
ブログ内検索

アクセス数
アクセスランキング
[ジャンルランキング]
日記
9506位
アクセスランキングを見る>>

[サブジャンルランキング]
会社員・OL
1766位
アクセスランキングを見る>>

天気予報
QRコード
QR
RSSリンクの表示
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。