「PostgreSQLは遅い」は本当か？：OSSデータベース比較

　LAMPやLAPPといった言葉が示しているように、オープンソースソフトウェア（OSS）での代表的なリレーショナルデータベース管理システム（RDBMS）といえば、「MySQL」と「PostgreSQL」だ。この2つのRDBMSは同等であるかのように思われているが、しかしPostgreSQLのユーザー団体「日本PostgreSQLユーザ会」で理事長を務める片岡裕生氏によれば、「PostgreSQLはあまり信用されていない」ということがあるそうだ。

　「十分にチューニングされたMySQLとチューニングしていないPostgreSQLを比較したり、反対にチューニングされたPostgreSQLとチューニングしていないMySQLを比較したり、あるいは比較する際のハードウェアそのものが違っていたりと、MySQLとPostgreSQLの性能比較は、客観的に行われていない」（片岡氏）

　そのように感じていた同氏は、客観的にデータベースの性能を調べたいという個人の集まりである「データベース性能検証会」の中で、MySQLとPostgreSQLをベンチマークを続けてきている。そのベンチマークの一部が、3月に沖縄で開催された「日本PostgreSQLユーザ会沖縄セミナー」の同氏の講演の中で紹介されている。

　なお、データベース性能検証会には、日本PostgreSQLユーザ会、MySQLのユーザー団体「日本MySQLユーザ会」のそれぞれに所属するメンバー両方が参加している。

単体テストからシナリオテストへ

　講演で紹介されたベンチマークは大きく分けて（1）ストアドプロシージャを使った単体テスト、（2）1サーバ1クライアントによるテスト、（3）1サーバ多クライアントでのテスト、（4）複雑なシナリオを利用したテスト、（5）接続してから最初のクエリが投げられるまでを計測する接続コスト――という5つからなる。

日本PostgreSQLユーザ会理事長の片岡裕生氏

　単体テストからシナリオへと、段々と複雑なものにするという方針について、同氏は「PostgreSQLとMySQL、強いところと弱いところ、それぞれの違いを見ていこう」という狙いを説明している。

　まず、ストアドプロシージャを利用した単体テストでは、INSERT、SELECT、UPDATE、DELETEの4つで行われており、4つとも、所定のレコード数の処理にかかった時間による計測が行われている。テストに用いられたデータは、1レコード64バイトを8つのカラムに分けた「64_8」、1レコード1kバイト（1024バイト）を128カラムに分けた「1024_128」、1レコード1024バイトを8カラムに分けた「1024_8」の3つ。レコード数はそれぞれ10万レコード。

　単体テストのINSERTの場合、「全体的にPostgreSQLの所要時間が長い」（同氏）という結果になっている。特に1024_128では、PostgreSQLはMySQLの約2倍の差がついている。この結果について同氏は「カラム数が多いとPostgreSQLが遅い」と分析している。というのは、「カラム数が少ないものでは、逆にPostgreSQLがMySQLよりも1.5倍より速いという結果が出ている」からだ。ちなみに同氏によれば、PostgreSQLのカラム数が多くなると処理が遅くなるという性能については「最新版である8.2で改善されている」という。

　SELECTの場合では、INSERTと逆転して「PostgreSQLの方が圧倒的に速い」という結果になっている。

　「“MySQLは検索が速い”とよく言われている。つまりMySQLではSELECTが速いと思われていた。しかし、PostgreSQLの方が速いという結果になった。このことについては、日本MySQLユーザ会の人たちとも“こういうことがあるんだね”と感心していた」

　UPDATEでは、INSERTと似たような傾向を示しており、結果としてPostgreSQLの方が遅いという結果になっている。これは「PostgreSQLが追記型というアーキテクチャになっているから」という。追記型であることで、「UPDATEで書き換えを行わない。内部的に元のデータをDELETEしてINSERTすることをやっている」としている。

　DELETEでの結果について同氏は、「PostgreSQLが全般的に速い」と語っている。「PostgreSQLでは、“削除”というフラグをつけているだけ。アーキテクチャの違いもあってPostgreSQLの方が速い」。

PostgreSQLのボトルネックは通信ではない

　ベンチマークの2番目になる1サーバ1クライアントのテストにおいて、INSERTではPostgreSQLが遅く、SELECTではストアドプロシージャほどの差は開いていないものの、約1.5倍PostgreSQLの方が速いという結果だ（1024_8ではMySQLの方が速い）。

　またUPDATEでは、単体テストと同じようにPostgreSQLが遅いという結果だ。しかし単体テストのようにMySQLとの差は1.5倍にはなっていないという。「クライアントとサーバに分けた場合、PostgreSQLとMySQLとの差は縮んでいる」。

　「MySQLはクライアントとサーバに分けると、その性能は落ちる。MySQLは同じマシンだと速いということだ。セキュリティの問題は別として、MySQLを利用する場合、ウェブサーバとDBサーバを同じマシンにした方が、性能は良くなる」

　その逆に、PostgreSQLであればローカルでも別々のマシンに分けても、性能が変わらないということになる。つまり「PostgreSQLのボトルネックは通信ではない」ということだ。

　ちなみに、1クライアント1サーバのDELETEでは、PostgreSQLは遅いという結果になっている。

バージョンアップで確実に性能が向上している

　3番目となる1サーバ多クライアントでは、クライアントの数を増やして並列に処理させるということをやっているが、処理するレコードの数は同じく10万レコードだ。このテストケースでは、MySQL内部のストレージエンジンの違いからMyISAM、InnoDB、InnoDB 5.1、PostgreSQL 8.0、PostgreSQL 8.1、PostgreSQL 8.2――という6つで比較。それぞれで、クライアントの数を0から500に増やしていく際に、その処理時間を計測するというテストだ。データの形は、単体テストや1クライアント1サーバと同じように64_8、1024_128、1024_8を用いている。

　64_8のINSERTでは、MyISAMはあまり速くないものの、InnoDBでかなり速くなってきている。しかしクライアント数が100から200になるところでは、性能が非常に遅くなるという。これがInnoDB 5.1では、クライアントの数が増えてくると、むしろ性能を上げるという結果だ。こうしたことから、同氏は「InnoDB 5.1を搭載するMySQLは、クライアントの数が多い方に設計されていることがわかる」と説明している。

　しかし同じ64_8でPostgreSQLを見ると、クライアントが100〜200を超えるところからPostgreSQLの方がむしろ速くなるという結果だ。「クライアントが増えるとMySQLは性能が落ちるが、PostgreSQLはそれほど性能が落ちることがない」。

　1サーバ多クライアントの1024_128のINSERTでは、MySQLは（MyISAMも含めて）全般的に速いという結果だ。PostgreSQLはクライアントが200台を超えるところから性能が落ちてしまう。これはPostgreSQL 8.0、PostgreSQL 8.1のプログラム上の問題なのだが、「8.2では問題が改善されている」という。そして1024_8では、MyISAMはあまり性能が良くならずに、PostgreSQLでは全体として、性能はそれほど変わらないという結果だ。

「PostgreSQLはバージョンアップで性能が向上してきている」と説明する片岡氏

　1クライアント多サーバのSELECTでは総じて「PostgreSQLにとっていい結果になっている」。64_8のケースでは、PostgreSQL 8.2が一番性能がいい。対するMySQLはどれも傾向が変わっていない。このことから同氏は「PostgreSQLは、8.0よりも8.1、8.1よりも8.2と順当に性能が上がってきている」と語っている。

　1024_128のケースでは、MySQLが遅いのに対して、PostgreSQLが速いという結果だ。1024_8のケースは64_8と似たような傾向を示している。

　ベンチマークの4番目になるシナリオテストは、単純なSELECTを処理するのではなく、複雑なSELECTを処理するというものだ。

　たとえば「TABLEを2つ結合して」から数件SELECTするというケースでは、PostgreSQLが遅いのに対して、MySQLは「割と速い」という結果が出ている。これが「TABLEを3つ結合して」から数件SELECTするというケースの場合、PostgreSQLは全体的に遅い。だが「TABLEを4つ結合してから」数件SELECTするというケースでは、「PostgreSQLが圧倒的に速い」となっている。

　5番目となる接続コストについて同氏は「“PostgreSQLは接続コストが重い”と言われていることと、“MySQLはマルチスレッドのモデルだから速い”と言われていることを検証したかった」と、その狙いを説明している。そうした背景の下で行った接続コストの結果だが、実際には「PostgreSQLは意外に速い」という結果になっている。

　このテストは、クライアントの数を0から1000台まで増やして、最初のクエリを投げられるまでの時間を計測するというものだが、PostgreSQLは総じてMySQLより速い処理時間となっている。しかし、クライアントの数が20台の付近では、MySQLよりも時間がかかってしまうという結果だ。なぜ、このような結果になるかについては原因が不明であり「今後検証していかないといけない」としている。

PostgreSQLは遅くない

　こうした検証結果からPostgreSQLの特徴について、片岡氏は「INSERTとUPDATEが遅い」としながらも、「“SELECTが遅い”というのは間違い、むしろ速い」とまとめている。また、8.1まではカラム数が多いと遅いという傾向だったが、バージョンが上がる度に性能は確実に向上していると説明している。

　さらに1サーバ多クライアントでの結果から、PostgreSQLは多クライアント環境で速いとしたうえで、「クライアント数をどうやって制限するかを考えるとよりも、サーバのメモリを増やして同時接続できる数を増やすという考え方をしたほうがいい。そうすれば結果として楽になれる」と語っている。

片岡氏は「PostgreSQLは商用と比較しても遜色はない」と語っている

　「“遅い”と言われるPostgreSQLだが、現行のバージョンであれば、ほかのOSSのRDBMSと比較して十分に速いことがわかった。商用のRDBMSと比較しても遜色はない。ただし絶対にチューニングは必要だ」

　片岡氏はまた、こうも語っている。

　「実務とかけ離れたベンチマークをしたことで、それぞれのDBMSが持つ“色”が見えてきた。つまり、それぞれのDBMSには性格、クセがある。その性格を理解して、もっとも効率のいい使い方をするべきだろう」