PostgreSQLを使う理由
作成中です - Mitsuhiro Yoshida 2008年1月22日 (火) 00:59 (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) をマスターおよびスレーブ間で分割しています。そして、この「データの書き込み直後に読み出す」ことは、相当数が発生すると予想されます。
And you also have to consider the performance boost of using async writes: if you tell a standalone Postgres or MySQL to use async writes, it'll run scale much better (should be able to handle up to 3-4 times more simultaneous writes). Once you do that, the performance advantage of the MySQL cluster mostly vanishes. It still has semi-hot takeover in case the master goes down, but Postgres can do that using Slony, and with better guarantess of consistency of the data in the slave.
In a nutshell, MySQL isn't normally very solid when it comes to ensure my data is safely stored on-the-disk, even if it theoretically guarantees that it's been saved. 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.
