zonkermanの日記： PostgreSQLのINSERT/UPDATEを数十倍高速化するSigres

SourceForge.jpにて、PostgreSQLのINSERT/UPDATEを高速化する Sigresというプロジェクトがあるのだが、 11日の Sigres-0.1.3のリリース発表において、このSigresは 通常のPostgreSQLに比べINSERTやUPDATEが数倍から数十倍高速化されているということが書かれている。 少々驚いたが、何となくwriteとfsyncの呼び出しを最小限にしているような感じである。 PostgreSQL開発者のBruce Momijian氏はメモリファイルシステムにWALファイルを置けばいいと考えているようであるが、 Sigresの開発者はそれでは大した性能向上はないことと、チェックポイントレコードすらメモリファイルシステム上にあるのは危険と述べている。 上流で議論を開始しているように見えるが、さて手法については皆さんどう思うだろうか？

この手の高速化って

[Anonymous Coward]

やったふりして仕事をためておいて、後でまとめて処理することで高速化をはかる、ただし破綻しない範囲で、ってことですよね。

私も昔、「やったよ」と返事だけしてためていました。夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、と言いたいとこですが…。そして今もその癖はなおっていません。

-- A.C., nothing more, nothing less.

Re:この手の高速化って

[kicchy (4711)]

＞私も昔、「やったよ」と返事だけしてためていました。
＞夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、
＞と言いたいとこですが…。そして今もその癖はなおっていません。

問題は、EoV実施フェーズにおいて
おなかを出して寝ていて風邪を引いたりなどの実施を
阻害する要因が出てきてしまうことを懸念しなくてはなりません。

今回の議論は、
絵日記は、後で出来るので遅延実施、
ただし、観察日記の場合、日記自体の書き出しは遅延出来るが
水やりなどはリアルタイムでやらなくてはならない。
この遅延させてよい事象と駄目な事象はどれなのかという議論
(WALファイルとかいうのが水やりに当たる？)
と
風邪を引かずに、うまく夏休みの終盤EoV実施フェーズを
乗り切るためのにどうすればよいかという
ことだと認識しておいてよいでしょうか？

Re:この手の高速化って

[Anonymous Coward]

Sigresプロジェクトの言い分は、

「8月31日にお父さんに手伝ってもらうことで処理の高速化を狙うと、その日残業だったり酔っぱらって帰ってきたときに危険である」

であり、それに対する反論としては

「お父さんはそもそも手伝ってくれない。せいぜい夜中に様子をみにきて、居眠りしていたら起こしてくれるだけ」

ということだと思われます。

-- A.C., nothing more, nothing less.

Re:この手の高速化って

[kicchy (4711)]

＞「8月31日にお父さんに手伝ってもらうことで処理の高速化を狙うと、
＞　その日残業だったり酔っぱらって帰ってきたときに危険である」

＞であり、それに対する反論としては

＞「お父さんはそもそも手伝ってくれない。
＞　せいぜい夜中に様子をみにきて、居眠りしていたら起こしてくれるだけ」

いいお父さんじゃないですか(´Д⊂

# そういう話じゃない？
# どちらも、「最後は自分の力が頼りである、
# 大事なのは夏休みの終わりまで宿題残さないこと」って主張に見えるけど... :-D

Re:この手の高速化って

[adeu (2937)]

モデレート権があればすばらしい洞察にしたいところ。

Re:この手の高速化って

[Anonymous Coward]

> 私も昔、「やったよ」と返事だけしてためていました。夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、と言いたいとこですが…。そして今もその癖はなおっていません。

私はさらに、やらなくて良いことはやらないことによって最適化を図る方法を開発しました。リスクは高いですが、夏休みの宿題なんて、バックれても問題はありませんでした・・・。

# そしてダメな大人になった

Re:この手の高速化って

[Anonymous Coward]

> 私はさらに、やらなくて良いことはやらないことによって最適化を図る方法を開発しました。

これは現在、コンパイラの最適化技術に適用されています。データフロー解析によって、まじめに処理してもしなくても結果に関係のない部分は省略されます。

たとえば、変数iを1増やす文だけを10万回ループさせる場合、ループせずにiに10万を加えて済ませます。そのiが後で使われなければ、この部分自体なくなります。

一連のコメントから、「夏休みの宿題」、特に「いかに逃れるか考える」ことが技術の発展に大きく寄与していることがわかりました。以上オフトピックすぎてごめんなさい。

Re:この手の高速化って

[Anonymous Coward]

割とよくある高速化方法ですね。
寡聞にして正式な名を知りません。

ここはひとつ、End Of Vacation - EoV手法と名づけて普及させましょう;-)

情報が少なすぎ

[kawaz (15398)]

リリースノートを見てもタレコミ文章以上の情報は無いし、
プロジェクトサイトを見てもやはり情報は無く、
フォーラムやMLのアーカイブにもやはり何の投稿も無い。

これで何を語れというんだろうか…？

「信頼性を犠牲」「効率的な挿入」「速い」

[Anonymous Coward]

エロい人のコメントでも待ちますか…

Re:情報が少なすぎ

[white (2295)]

同感。「ソース読め」状態なせいで癖とか勘所がわかりにくいので、
試験的に使ってみるにしてもちょっと踏み切りにくいですね。
「tmpfsだと遅い」というのはkernelのファイルシステム層がオーバーヘッドになってるってことでしょう。
だとすると、WALの管理のうちファイルシステム任せにしてる部分を自前管理に変更してる…のかな？
# 憶測なんでその程度しか信用しないように。為念。

Sigres自体は2006年度上期IPA未踏ソフトウェア創造事業の採択プロジェクトで作られたもののようです。
http://www.ipa.go.jp/jinzai/esp/2006mito1/gaiyou/4-37.html [ipa.go.jp]
先日報告会があったようですが詳細なレポートなどは発見できず。

あと、0.2への構想(マルチコアを前提としたWAL実行の並列化)もあるみたいで。
http://lists.osdn.jp/mailman/archives/sigres-all/2007-February/000002.html [osdn.jp]

Re:情報が少なすぎ

[kabaolaf (33678)]

開発者の川島です。 文書がなくて申し訳ありません。 Sigresの基本哲学は、信頼性を若干犠牲にして、性能を向上させることです。 それゆえ現時点ではミッションクリティカル向きではありません。 しかし、不揮発メモリが当たり前の時代になれば、Sigres方式をあらゆるDBMSが使うようになるでしょう。 Sigres-0.2.0ではXLogInsertレベルでの高速化を実現します。 他にもH2やMySQL/Falconでの高速化を設計中です。 コメント、ご意見など、どうぞよろしくお願い申し上げます。

Sigresの開発者に同意

[Anonymous Coward]

メモリファイルシステム上にチェックポイントレコードを置いて、電源落ちた時どう整合性とる
のでしょうか。
整合性をとれないのならRDBMSとは言えないですよ。

Sigresの開発者は勘違い

[Anonymous Coward]

チェックポイントレコードのキャッシュをメモリ上においているだけ。 本体はファイルに書き出している。何の問題も無い。

Re: Sigresの開発者に同意

[to (16347)]

リレーショナルデータベースを管理するシステムであれば、整合性が取れる取れないに関係なくRDBMSと言っても良いと思います。

Re: Sigresの開発者に同意

[koedoyoshida (30078)]

自由放任でも管理と言えるならRDBMS。

RDBにおける成果主義？
マネジメントシステム(上司)が選べるRDBっていうのは良いかもしれない。

...俺はそんなマネジメントシステム使ってるRDBは使いたくないが。

Re: Sigresの開発者に同意

[Anonymous Coward]

RDB「M」Sの要件にどこまで含まれるかって話じゃないの？
とりあえず動けばいいって物じゃないんだし。

Re: Sigresの開発者に同意

[Anonymous Coward]

大丈夫。

UPSをつければ、電源が1回落ちる間にLinuxカーネルは100回は落ちるから。
『電源が落ちたときは』深く考えなくても (^o^)。

# 当たり前と言えば当たり前だが、高い負荷がかかるとかなりの確率でこける。
# RHEL4 だと U4 でも、Vanilla 2.6.17 で出たこのパッチが当たってないとか
#
# commit 993dfa8776308dcfd311cf77a3bbed4aa11e9868
# Author: Trond Myklebust <[e-mail]>
#Date: Fri Mar 31 02:30:55 2006 -0800
# [PATCH] fs/locks.c: Fix sys_flock() race

Re: Sigresの開発者に同意

[Anonymous Coward]

＞メモリファイルシステム上にチェックポイントレコードを置いて、電源落ちた時どう整合性とるのでしょうか。
＞整合性をとれないのならRDBMSとは言えないですよ。

全部Roll backするという手があります。IMSのMSDB(めいんすとれーじでーたべーす)がそれです。（あれはRDBじゃないけどね）

# 中の人なので本当にAC

Re: Sigresの開発者に同意

[Anonymous Coward]

そこが「UPSの存在を前提」＝「電源が落ちたときのことは考えない」ということでしょう。
だからって安心できるわけじゃないけど・・・

Re: Sigresの開発者に同意

[JBD01226 (10061)]

マシンが突然リセットしたり電源が死んだ時の話だとどうなるんだろう。
たとえばRAIDカードはバッテリが乗っかっててマシンが不意にリセットされてもキャッシュを保持したりする。

Re: Sigresの開発者に同意

[Anonymous Coward]

こけても問題ないプライベート用途か、すべてのポイントで障害対策を講じてあるエンタープライズ用途以外は使うなということかな?

Re: Sigresの開発者に同意

[pollux (23211)]

ずいぶん昔、OracleがREDOログをsyncなしででwriteしてそれだけのことで3倍ぐらい
早くなったそうです。Linux用のベータ版でのバグでもちろんOracleはすぐに直してます。
こういう内容ならそれはバグであって、早くなる方法とはいえないでしょう。
えらい人、教えて。

門外漢ですが

[Anonymous Coward]

あのぅ、これ以上メモリ食わないでくださぃ

Re:門外漢ですが

[okky (2487)]

私も門外漢ですが。

今の DBMS は read/write でデータを読み書きしている。write はともかく、read の方は、
read only な mmap にしてくれないかな。変更するときにコピーをとって write するって事で。

というのは、read/write は kernel 側と DBMS 側に1つづつページのコピーを持っている。
kernel 側は「手元にあるこのキャッシュのコピーは、DBMS 側がもっているあのページと
同じものだ」という事が判らないので(read とは「コピーしてよこせ」という意味ですので)
これじゃ、4Gあったとして、全部データに使えても実質2Gbyteしか使えない事になる。
mmapなら kernel cache と DBMS 側のページが「同じもの」と判るので、少しだけでも
この無駄が減る。

高速化の前にこの辺の無駄を削ってからの方が、トータルスループットが快適に上がると思うだが…。

--
fjの教祖様

Re:門外漢ですが

[L.star (163)]

今のPostgreSQLのボトルネックは、8.1以降大きく解消したとはいえ各種内部ロックなので、mmap()にしてもそんなに快適にはならないような気がする。

それに、キャッシュのヒット率を上げるなら、メモリの有効活用よりバッファアルゴリズムを改良するとか他にやることがある。まあ、mmap()辺りの話は昔からずっと言われている割には全然実現していないので、移植性の問題か、はたまたみんなやる気がないのかな、とか思っている。

64bits向けなら好し(?)

[Anonymous Coward]

( mmap() + munmap() ) × n は
fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、
一般的な32bits環境では mmap() しっぱなしでどうにかなる
全体が4GB未満のデータベースでしか速くならない
ってことになるんじゃないですかね。

Re:64bits向けなら好し(?)

[okky (2487)]

うーん。 mmapを使う事でコピーを減らしてメモリの利用効率が上がると、n の数自体が減ると思いますが。 # 十分多きな DB に対しては変わらんか。 あと、前から思っているんだけれど… > ( mmap() + munmap() ) × n は > fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、 これ本当かなぁ?? いや、advice なしで mmap/munmap 使ったら、sequential read では、遅いのは全くもってその通りと思うけど…。 # 文字通りの on demand になるので、4kbyte づつ粉々に、ランダムに読み込むのに等しい。 # それなら、fread() がキャッシュを使って、一気に数Mbyte読むように仕向ければ、 # 圧勝だろう、と私も思う。 『HDDとのIOが支配的』な世界では、madvise で MADV_SEQUENTIAL と MADV_WILLNEED 与えれば、実質 fread() と同じ HDD IO 挙動をしてくれるはず。順番にアクセスするぞ、必要になるぞ、さぁ先読みしろ、と教えるわけですから。『大抵遅い』になるとは到底思えない。 # 時間が出来たら実験しよう…。

--
fjの教祖様

Re:門外漢ですが

[Anonymous Coward]

そこで、GNU Hurdですよ

forkせずにパッチで配れば？

[Anonymous Coward]

• PostgreSQL8.2.1ベースだから、CVE-2007-0555やCVE-2007-0556の脆弱性を抱えたままですよ。
• 今後のメンテも考えれば(セキュリティ対応も然り)、forkせずにパッチとしてリリースし、最終的には本家に取り込んでもらう方向で進めた方がいいんじゃないかなぁと。PostgreSQL8.2.1とdiffをとってもさほど大きくないし(22KB程度)。

Re:forkせずにパッチで配れば？

[Anonymous Coward]

取り込んでもらうためにパッチを提出したそうです。初めはいい感じの反応をもらっていたそうなんですが、

PostgreSQL開発者のBruce Momijian氏はメモリファイルシステムにWALファイルを置けばいいと考えているようである

で、おあずけのようですよ。