カテゴリー: Database

PostgreSQL 8.1リリース

実はリリースされていた事は知りつつスルーしていたのですが微力でも宣伝を。

PostgreSQL 8.1は本当に速いでも紹介していたPostgreSQL8.1がリリースされています。

速いだけでなくうれしい新機能も盛り沢山です。是非使ってみてください。

新しい、先進的データベース機能

ロール:PostgreSQLがデータベースロールをサポートするようになりました。ロールにより、データベース権限が複雑に関連し合うような大規模なユーザ管理が簡単に行うことができます。

IN/OUTパラメータ:PostgreSQLの関数がIN、OUT、INOUTパラメータをサポートするようになりました。これにより、J2EEや.NETアプリケーションにおける複雑なビジネスロジックのサポートが改良されました。

2相コミット(2PC:Two-Phase Commit):2PCはWAN環境におけるアプリケーションで長い間待ち望まれていた機能です。広域ネットワーク上に分散したサーバ間でACID特性を持つトランザクション処理を可能にします。(訳注:「ACID」とは、Atomicity(原子性)、Consistency(一貫性)、Isolation(隔離性)、Durability(耐久性)の頭文字です。)
性能の改善

マルチプロセッサ(SMP)環境における性能改善:バージョン8.1におけるバッファ管理機構は、8-way、16-wayシステムやデュアルコア、マルチコアCPUのサーバにおいて、プロセッサ数に対してほぼリニアにスケールします。

ビットマップスキャン:インデックスは状況に応じて自動的にメモリ内部でビットマップに変換されます。この機能によって、大規模テーブルに対する複雑な問い合わせのインデックス検索が20倍以上高速化されます。また、複数列に対するインデックスを作成する必要性が減少し、データベース管理が簡単になります。

テーブルパーティショニング:バージョン8.1では、制約による排他といわれる技法を用いて、問い合わせプランナが大規模なテーブル全体をスキャンしないようになりました。他のデータベース管理システムにおけるテーブルパーティショニング同様、これにより数ギガバイトのテーブルに対する性能とデータ管理が改良されました。

共有行ロック:PostgreSQLの「行レベルロックよりも優れた方法」に、共有行ロックの機能を追加することで、より高い同時実行性をサポートできるようになりました。共有ロックにより、大量のOLTPを必要とするアプリケーションでの挿入・更新の性能が向上するはずです。

Reliable Computer Solutionsのデータベース管理者であるMerlin Moncureは次のように述べています。「PostgreSQL 8.1によって(私たちの)Opteron デュアルプロセッサ運用用サーバで非常に大きな性能向上が実現しました。具体的にいうと、CPU負荷において20%、サーバの負荷特性においては20から40%もの性能向上が見られました。」

この他にも120項目以上におよぶ改良が行なわれています。詳しくは8.1 プレスキットを参照してください。

ダウンロード: http://www.postgresql.jp/PostgreSQL/download.html
日本PostgreSQLユーザ会: http://www.postgresql.jp/
PostgreSQL Project: http://www.postgresql.org/

MySQL 4.1, 5.0の文字化け回避

日本人には必要なオプションがmysqldのオプションに追加されたようです。4.1.15、5.0.15以降なら使えるそうです。

A new command line argument was added to mysqld to ignore client character set information sent during handshake, and use server side settings instead, to reproduce 4.0 behaviour (Bug #9948):

mysqld –skip-character-set-client-handshake

ちょっと乱暴ですがPostgreSQLなら「initdbのオプションに–no-localeを付ける」にあたいするくらい重要かも知れません。

MySQL5リリース

#ちょっと遅いのですが自分用のメモとして。

10/24にMySQL5が正式リリースされました。

新しい機能として

  • ストアドプロシージャ
  • トリガ
  • カーソル
  • スキーマ
  • XAトランザクション

サポートされています。

FEDERATED Tablesと呼ばれる他のMySQLサーバのテーブルとリンクする機能も追加されたようですがこれはPostgreSQLのdblinkと同類の機能ですね。

dblink/
ここには2つの関数が提供されています。1つ(dblink())はリモートデータベースに 対して実行したいSQLのクエリーの結果をポインタを受け取るものです。引数を2つ (接続するデータベースを標準のlibpq形式で記述したものと実行したいSQL文)渡すだけで リモートデータベースから結果を受け取ることができます。もう1つはdblink()の結果から 各フィールドの結果を文字列で返すものです。構文や使用例は、このディレクトリにある README.dblinkを参照してください。

http://www.sraoss.co.jp/PostgreSQL/7.2/contrib.html

PostgreSQL 8.1は”本当”に速い

@ITのDatabase Watch 10月版に「PostgreSQL 8.1は”速い”とうもっぱらのうわさ」と記事があります。

「うわさ」ではなく「本当」に8.1は速いです。

ミッションクリティカルなシステムでpgpoolを使用している所も多いと思いますが、8.1+pgpoolの相性は良いようです。pgpool無しで直接PostgreSQL8.1にアクセスした場合、pgpoolでPostgreSQL 8.1 2台でロードバランスさせてベンチマークするとINSERT、UPDATE、SELECT全てのケースで処理効率が向上している事が分かります。特に
SELECTのみクエリは100%以上の効率化となるベンチマーク結果(私が計測したケースでは102%)となる場合もあります。
# つまり2台にした場合、2台分よりも速くなるケースがある。
# 負荷を分散させたため各サーバがより効率良くクエリを実行できた
# ため論理値以上である102%の速度向上が見られたと考えられます。

私は試していませんが片岡さんに聞いたところ8.1では同時接続数が増えてもスループットの低下が少ないという情報も聞きました。500接続くらいではあまり速度低下が発生しないそうです。

私も8.1はまだまだテスト中ですがPostgreSQLの性能でお困りの方は8.1をテストしてみてはいかがでしょうか?

Oracle、オープンソースソフト企業のInnobase買収

ITMediaの記事から少し驚いたニュースを見付けました。

 米Oracleは10月7日、フィンランドのオープンソースソフト企業Innobase OYの買収を発表した。買収条件は非公開。

InnobaseはMySQL4.1からデフォルトのデータベースエンジンとなったInnoDbの開発元です。InnoDbはトランザクションをサポートする高機能なデータベースエンジンです。一方、MySQL4.1より古いバージョンではトランザクションをサポートしないMyISAMがデフォルトのデータベースエンジンでした。

当然ですがこのニュースはInnobaseのサイトにも載っていました。

Oracle Announces the Acquisition of Open Source Software Company, Innobase – Oracle Plans to Increase Support for Open Source Software

Oracleのニュースリリースはこちら

InnoDB’s contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship. Terms of the transaction were not disclosed.

一応OracleはInnobaseとMySQLとの契約が延長されることを望んでいるらしい。
クリティカルな用途でMySQLを利用しているユーザは将来的にはどのような状態になるか非常に気になるのではないか、と思います。

Oracleのニュースリリースには「Oracleha今までもLinux、Apacheなどのオープンソース製品をサポートしてきた」とオープンソースコミュニティへの貢献の実績を書いていました。しかし、OSやWebサーバはOracleデータベースと競合関係にありませんが、データベースは競合関係であるため同じようにサポートできるはずがありません。すぐには動きが無くても長期的にどうなる興味があります。

Explaining Explain日本語版ドラフト

JPUG広報部ブログにOSCON2005で発表された「Explaining Explain」の日本語版ドラフトが公開されています。

EXPLAINとはPostgreSQLのコマンドで、クエリの実行プランや実際の実行時間を表示させる為に使います。SELECT min(val) FROM my_table; が何故遅いのか等、が解るツールです。クエリの最適化、PostgreSQLサーバの設定ファイル(postgresql.conf)のrandom_page_costの最適化などには欠かせないコマンドです。

非常に参考になります。もし読まれた事がない方はぜひどうぞ。

Slony-II

ThinkIT(要登録)にSlony-IIプロジェクトの紹介がありました。こんどはNTTデータも開発に参加するようですね。

Slony-Iは非同期方式のマスタースレーブ型のレプリケーションでしたが、Slony-IIでは同期式になるようです。PGClusterの強力なライバルとなりそうですね。個人的には

非同期ならpgpool
– 同期ならPGCluster

をお勧めしたい :)
# 別にSlony-I、IIが悪い、と言っている訳ではないです。念のため。

PostgreSQL 8.1のパフォーマンス

PostgreSQLのパフォーマンスはpostgresql.confに大きく影響されるので、速くなったかどうか判りづらい場合も多いです。しかし、8.1では確実に速くなっているようです。現在8.1はbeta1ですが少しだけ比較してみました。

詳しくはWikiのページを見ていただくとして以下の様にpgbenchで計測すると

./pgbench -v -h 192.168.100.204 -U yohgaki -c 20 -t 200

PostgreSQL 8.0.3

tps = 4683.835265 (excluding connections establishing) (Select only)
tps = 1032.798585 (excluding connections establishing) (Update 省略)
tps = 423.926137 (excluding connections establishing)

PostgreSQL 8.1beta1

tps = 5985.801678 (excluding connections establishing) (Select only)
tps = 1428.605103 (excluding connections establishing)(Update省略)
tps = 533.005286 (excluding connections establishing)

という感じの結果になりました。
postgresql.confの設定は多少チューニングした物を使っています。postgresql.confもWikiのページに添付してあります。

pthread版pgbenchの拡張

実はpthread版pgbenchの作成には別の目的もあります。オリジナル版pgbenchのコードを見ると分かるのですが、非同期クエリを使用しているので送信するクエリのカスタマイズが面倒です。pthread版pgbenchの別の目的、と言うより本来の目的、はpostmasterが書き出したログから自動的にクエリを収集し、再生するベンチマークを簡単に行いたいので作る、と言う事にあります。

今の所こんな感じで実装するつもりです。

postgresql.confのログ設定が

log_line_prefix = ‘%r’
log_statement = true

で出力されたログから自動的に各クライアントのクエリを出力し設定されたスレッド数(クライアント数)でベンチマーク出来るようにする予定です。

今のコードだとログの読み取りとクエリ保存を行えるようにして、各スレッドがクエリを実行するように変更すれば良いだけです。簡単なのでそのうち変更します。

pgbenchのpthread版

(やはりバグを発見したので修正)

JPUG広報Blogに「pgbenchのpthread版が欲しい」と書いていましたが、先週末にPHP関西のセミナー講師を引き受けていたのでその移動時間中にテキトーに作ってみました。テキトーに作ったので勘違いしてバグを入れていました。今度はたぶん正しい結果になっていると思います。

サーバ環境
Athlon64 3200/3GB Memory/SATA2 HDD/Momonga Linux x86_64
PostgreSQL 8.0.3(64bit)(全てのSQL文をホスト/ポート付きで記録。他はほぼデフォルト。)

クライアント環境
AthlonXP 2500+/2GB Memory

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 10 -t 100
starting vacuum…end.
starting full vacuum…end.
Warming up 15 seconds…
Start benchmarking…
End benchmarking….. (4.96586 seconds)
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 100
total number of transactions processed: 1000
tps = 235.404176 (excluding connections establishing)

real 0m25.739s
user 0m0.214s
sys 0m0.313s
[yohgaki@dev pgbench]$

こんな感じです。

何だか遅くなってしまたのでコードをもう少し効率化してみました。
今度はオリジナル版よりは速くなりました。

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
Warming up 0 seconds…
Start benchmarking…
End benchmarking….. (1.16363 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 429.689481 (excluding connections establishing)

real 0m2.655s
user 0m0.047s
sys 0m0.088s

オリジナル版

[yohgaki@dev pgbench]$ time pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
number of transactions actually processed: 500/500
tps = 337.674248 (including connections establishing)
tps = 379.093451 (excluding connections establishing)

real 0m1.615s
user 0m0.043s
sys 0m0.210s

と、多少スレッド版の方が速いです。今度は繰り返し実行してみてもスレッド版の方が速い傾向は変わりませんでした(汗

ベンチマークを開始する前にウォーミングアップの時間を設定したかった事、クエリ実行間隔をランダムに設定したかった事もpthread版が欲しかった他の理由でした。そこで

-w ウォームアップ時間(秒)
-r ランダム遅延(マイクロ秒)

も設定できるようにしました。よくあることですがサーバに負荷をかけた直後は良い性能がでるためウォームアップ時間は設定できた方が便利です。

ウォームアップ時間を5秒に設定した場合

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10 -w 5
starting vacuum…end.
starting full vacuum…end.
Warming up 5 seconds…
Start benchmarking…
End benchmarking….. (1.48874 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 335.854481 (excluding connections establishing)

real 0m6.671s
user 0m0.124s
sys 0m0.260s

とこの様な感じです。オリジナル版にウォームアップ時間オプションを追加して欲しいな、と書いておいたら石井さんが追加してくれるはず :)

ソースは
http://www.ohgaki.net/wiki/index.php?PostgreSQL%2Fppgbench
からダウンロードできます。変更するかもしれないので日付を入れておきました。日付が入っていないソースは古いソースです。もし古いソースをお持ちの場合、新しいソースを使ってください。古い物にはバグがあります。

pgpool 2.6 alpha

pgpool 2.6の人柱を募集中とのことです。こういったものは広く告知した方がよいのでpgsql-jp MLのメッセージをそのまま貼り付けます。

石井です.

久々にpgpoolのバージョンアップをしようとしています.ついては,できたばかりのV2.6のアルファ版を,

http://www2b.biglobe.ne.jp/~caco/pgpool/tmp/pgpool-2.6.tar.gz

に置きましたので,人柱になっても良い,という方は是非ご協力をお願いします.

2.6の目玉は,SERIAL型への対応です.といっても,やっていることはごく単純で,INSERT文があったらそのテーブルに自動的にテーブルロックをかけるだけです.トランザクションの並列実行性は犠牲になりますが,SERIAL型の列がマスタとセカンダリで一致しなくなることは防げます.

ちなみに自動ロックの機能はSERIAL型を含まないテーブルにも働いてしまいます:-)回避方法はREADME.euc_jpをご覧下さい.

以下,2.5.2からの変更点のリストを付けておきます.
——————————————————————-
o pool_error etc.で,asprintfの後でfreeしていなかったのを修正.

o main.cで,mallocのサイズが誤ってpool_config.num_init_children
* sizeof(pool_config.num_init_children)
になっていたのをpool_config.num_init_children * sizeof(pid_t)に修正.

o parameter statusの値が一致していなくてもエラーにならないようにした(USとNZでレプリケーションしている例があった!).

o pgpool stopで終了せず,一旦killされた後,pgpool -m f stopを受け付けなくなるバグを修正.

o 新しいディレクティブinsert_lockを追加.trueの場合,INSERT実行時に自動的にテーブルロックを行う.これにより,SERIAL型を含むテーブルの同期を取ることができる.なお,/*NO INSERT LOCK*/コメントを付けると,そのINSERT文のみテーブルロックを行わない.あるいはinsert_lockがfalseでも/*INSERT LOCK*/コメントを付けるとテーブルロックを行う.

o 2.5.2で追加された「strictモードであっても,SELECTだったらsecondaryの完了を待たない」仕様を取りやめ.代りに,/*NO STRICT*/コメントを追加.

o show pool_statusに新しい情報を追加.縮退やフェイルオーバ状況を分かりやすく表示するようにした.
server_status| master( on 5432) up secondary( on 5433) down| server status
——————————————————————-

Tatsuo Ishii

MySQL 5のデータベースエンジン

mysql> SHOW ENGINES;
+————+———+————————————————————+
| Engine | Support | Comment |
+————+———+————————————————————+
| MyISAM | DEFAULT | 高性能のMySQL 3.23以降のデフォルト・エンジン|
| HEAP | YES | MEMORY のまたの名前 |
| MEMORY | YES | Hashベースで、メモリー内に格納、テンポラリ・テーブルに適す。|
| MERGE | YES | 同一のMyISAMテーブルのコレクション  |
| MRG_MYISAM | YES | MERGE のまたの名前 |
| ISAM | NO | もう使われないストレッジ・エンジン、MyISAM を使用のこと。 |
| MRG_ISAM | NO | もう使われないストレッジ・エンジン、MERGEを使用のこと。 |
| InnoDB | YES | トランザクション、行レベルのロッキングとフォーリンキーのサポート |
| INNOBASE | YES | INNODB のまたの名前 |
| BDB | YES | トランザクションとページレベルのロッキングをサポート |
| BERKELEYDB | YES | BDB のまたの名前 |
| NDBCLUSTER | NO | クラスタ、耐障害性のメモリー・ベースのテーブル |
| NDB | NO | NDBCLUSTER のまたの名前 |
| EXAMPLE | NO | ストレッジエンジンの例 |
| ARCHIVE | NO | アーカイブ・ストレッジエンジン |
| CSV | NO | CSV ストレッジエンジン |
+————+———+————————————————————+

メモリ上にだけ存在するデータベースはPostgreSQLにも欲しいですね。CREATE TEMP TABLEを拡張して実装とか?

ちなみにSQLiteはメモリ上にデータベースを持てます。MSDEもメモリ上にデータベースを持てたと思います。もう何年も前になりますがIMDB(In Memory Database)として話題になっていました。

PostgreSQLをハックするならIMDBの実装しかない?!