QA@IT
«回答へ戻る

modernized comment

2024
 
 大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。
 
-たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。
+たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、何度繰り返しても同じメモリ位置のそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。
 
 追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。
 
 
 ## 更に追記
 
-tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。
+tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体は(一部ではなく全部が)コピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeなら完全に局所化されたvalueだけの上書き処理ですが、追記だと良くても (key1, key2, key3, value) 全体のコピー処理です。これは、ゼロコピー化やCopy-on-writeなどでコピー量を極限まで減らそうという最近のトレンドに反するもので、また行サイズが大きくなればなるほど性能差は顕著になります。メモリやI/Oの帯域的にも空間的にも無視できない無駄です。
 
 なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。
 

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、何度繰り返しても同じメモリ位置のそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体は(一部ではなく全部が)コピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeなら完全に局所化されたvalueだけの上書き処理ですが、追記だと良くても (key1, key2, key3, value) 全体のコピー処理です。これは、ゼロコピー化やCopy-on-writeなどでコピー量を極限まで減らそうという最近のトレンドに反するもので、また行サイズが大きくなればなるほど性能差は顕著になります。メモリやI/Oの帯域的にも空間的にも無視できない無駄です。

なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

## 追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、何度繰り返しても同じメモリ位置のそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

## 更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体は(一部ではなく全部が)コピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeなら完全に局所化されたvalueだけの上書き処理ですが、追記だと良くても (key1, key2, key3, value) 全体のコピー処理です。これは、ゼロコピー化やCopy-on-writeなどでコピー量を極限まで減らそうという最近のトレンドに反するもので、また行サイズが大きくなればなるほど性能差は顕著になります。メモリやI/Oの帯域的にも空間的にも無視できない無駄です。

なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

edit

2024
 
 tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。
 
-なお、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。
+なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。
 
 また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。
 

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。

なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

## 追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

## 更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。

なお、公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

edit

2024
 追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。
 
 というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。
+
+## 更に追記
+
+tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。
+
+なお、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。
+
+また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。
+
+なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。

なお、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

## 追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

## 更に追記

tabizouさんから、PostgreSQL 8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体はコピーされます。つまり (key1, key2, key3, value) のようなタプルでvalueを+1する処理を考えるとき、in-placeならレジスタかL1キャッシュライン上でvalueのみの完全に局所化された演算処理ですが、追記だと良くても (key1, key2, key3, value) 全体のL2上でのコピー処理です。この2つはざっと数十倍のコスト差があります(行サイズが大きくなればなるほど顕著です)。もっとも実際にはロックのほうがコストが高かったりするのですが、それでも帯域的にも空間的にも無視できない無駄です。

なお、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。また、5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。

また、HOTを効かせるためにFill factorを下げると空間効率が落ち、Fill factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。」と表現しました。

なお、NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。MongoDBの場合には、逆にドキュメント(=行)単位のpadding factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。

edit

2024
 
 大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。
 
-たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれます。これは、冪等性を担保しつつMVCCを実現するという論理的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。
+たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。
+
+追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。
 
 というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

## 追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。

追記型アーキテクチャは、冪等性を担保しつつMVCCを実現するという理論的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

edit

2024
 
 * http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
 * http://wekeroad.com/2012/07/19/postgresql-rising
+
+## 追記
+
+大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。
+
+たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれます。これは、冪等性を担保しつつMVCCを実現するという論理的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。
+
+というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれます。これは、冪等性を担保しつつMVCCを実現するという論理的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

## 追記

大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。

たとえば、アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、キャッシュされてる同じページのそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれます。これは、冪等性を担保しつつMVCCを実現するという論理的な意味ではよりシンプルで美しいのですが、Disk I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。また、これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。

というわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。

edit

2024
 * RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
   * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
 * 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
-  * PostgreSQLはマルチプロセス、MySQLはマルチスレッドだが、やはり接続数が増えてくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
+  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
   * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
   * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
 * データのカッチリ感ではPostgreSQL

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッド。やはりサーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising

回答を投稿

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

  • まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
  • RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
    • MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
  • 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
    • PostgreSQLはマルチプロセス、MySQLはマルチスレッドだが、やはり接続数が増えてくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
    • レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
    • 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
  • データのカッチリ感ではPostgreSQL
    • 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
  • MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

Flame warにもってこいの燃料投下ですね。 :)

元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、

* まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。(Oracle RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)
* RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。
  * MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。
* 大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、
  * PostgreSQLはマルチプロセス、MySQLはマルチスレッドだが、やはり接続数が増えてくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)
  * レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Percona XtraDB Clusterとかもある。
  * 実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。しかもアクティブに。
* データのカッチリ感ではPostgreSQL
  * 歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。
* MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。

などなど。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。その必要十分感もあってか、最近Hacker Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。

MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。が、本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。

以下、最近目にした関連リンクです。ご参考まで。

* http://ledgersmbdev.blogspot.com/2012/09/or-modelling-interlude-postgresql-vs.html
* http://wekeroad.com/2012/07/19/postgresql-rising