PostgreSQLを使う理由

作成中です - Mitsuhiro Yoshida 2008年1月28日 (月) 10:53 (CST)

Martin Langhoffは、PostgreSQLの使用をお勧めします。 (出典: Moodle over webct and LNLS at Athabasca University? forum posting)

Postgresを選ぶ理由はいくつかありますが、簡単な要点をまとめてみます。私たちは、Catalystで様々なRDBMS (Oracle、Postgres、MySQL、ProgressおよびいくつかのRDBMS) を動作させ、社内で数多くの経験があります。また、私たちはデータベースのレプリケーション、クラスタリングおよび他の技術 (tricks) に関して経験があります -- .nzルートドメインサーバのバックエンド、そしていくつかのミッションクリティカル (極めて重要) なシステムにこれらの技術使っています。

パフォーマンスに関して、Postgresは最初の設定がMySQLよりも少しだけさらに必要です。適切に設定されたPostgresは、小さなMySQLデータベースのSELECTパフォーマンスにおいて、非常に近くなります。大きなテーブルではMySQLにパフォーマンスの問題がありますが、Postgresは快適に動作します。

また、書き込み (write) パフォーマンスでMySQLに問題があります -- トラフィックが多い場合、同時書き込みに深刻な問題があります。高負荷の場合でも、Postgresは快適に動作します。

しかし、本当のことを言えば、Postgresを選択する真の理由は「信頼性」です。私たちは数多くのデータベースを管理しています。Postgresには磐石の信頼性があり、ACID (Atomicity, Consistency, Isolation, Durability) に重点が置かれています。またPostgresでは、コミットから戻る時点でデータは安全にディスクに保存され、私たちが使用しているRAID1に実際のディスクトラブルがない限り失われることはありません。私たちが何度試してみても、頻繁に使用されるMySQLデータベースでは、インデックス破損の問題が生じました。あなたがMySQLのスタートアップスクリプトを確認してみると、ほとんどのLinuxディストリビューションでは、スタートアップ毎に破損データをチェックします -- このチェックにより、インデックスの破損が頻繁に起きている事実を覆い隠しています。

そして、これは比較的小規模かつデータがミッションクリティカルではない組織では通用しますが、あなたはこのようなアプローチをどれほど信頼できるか考慮すべきです。また、大規模なデータセットでは、isamchk/myisamchkの実行に数時間かかってしまいます -- 私たちは、そのような時間を割くことはできません。

MySQLのクラスタリングソリューションが喧伝されていますが、根本の問題から注意をそらしているのだと私は思います。それに対する私の主な関心事は、MySQLクラスタリングでは「非同期」にデータが書き込まれることです -- つまり、あなたのデータがディスク上に安全に書き込まれるという保証はないということです。あなたのデータは、時々ディスクに到達します。そして、時々 ．．．スレーブに到達します。Hmmm.

MySQLクラスタがasync (非同期) 書き込みを使用することを前提として、私たちがデータを書き込んだ後、そのデータを即座 (または直後) に読み込む場合でも、MySQLは万が一に備えて、読み込み/書き込み (read/write) をマスターおよびスレーブ間で分割しています。そして、この「データの書き込み直後に読み出す」ことは、相当数が発生すると予想されます。

そしてまた、あなたはasync (非同期) 書き込みを使用したパフォーマンスブーストを考慮すべきです。あなたがスタンドアロンのPostgresまたはMySQLでasync (非同期) 書き込みを実行する場合、さらにスケールを改善することができます (通常の3-4倍の同時書き込みを処理できます)。一旦、あなたがasync (非同期) 書き込みを使い始めると、MySQLのパフォーマンスにおける利点は、ほとんど消滅してしまいます。マスターのダウン時に備えて、MySQLではセミホット・テイクオーバー (引継ぎ) を保持したままですが、PostgresではSlonyを使用することができ、スレーブにおけるデータの整合性がさらに保証されます。

極めて簡単に言えば、私のデータが安全にハードディスクに保存されたと保証されても、仮にデータが保存されたと論理的に保証されたとしても、通常MySQLは非常にソリッド (solid 確かな、安定した) というわけではありません。And MySQL Cluster says up-front that there isn't a guarantee any more. Riiiiiight wink

Michael is talking about having UPSs. We have a car-sized UPS and a container-sized on-site generator that auto-starts. And yet, I wouldn't depend on that for my DB consistency on a large Installation. So many things other than power can (and do) go amiss. If a process has a problem storing the data, the right thing is to tell that back to the user. With async (非同期) writes, you end up with a queue of data that hasn't been stored yet, but you already told the user it was.

That's not what a database is supposed to do.

I am currently exploring some techniques similar to those being used in livejournal and slashdot. We should be able to increase Moodle scalability by cutting down on DB load by about 50%. This is happening slowly in the gaps between more urgent projects. Feel free to ping Richard or me if you're interested in that track.

関連情報

• Installing Postgres on Ubuntu(Debian)