ソースを表示

Martin Langhoffは、'''PostgreSQLの使用'''をお勧めします。 (出典: [http://moodle.org/mod/forum/discuss.php?d=24831#121862 Moodle over webct and LNLS at Athabasca University?] フォーラム投稿)

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では[http://slony.info/ Slony]を使用することができ、スレーブにおけるデータの整合性がさらに保証されます。

極めて簡単に言えば、私のデータが安全にハードディスクに保存されたと保証されても、また、仮に論理的に保存されたと保証されたとしても、通常MySQLは非常にソリッド (solid 確かな、安定した) というわけではありません。MySQLクラスタに至っては、前もって、これ以上の保証はないとされています。Riiiiiight wink

マイケル (Michael) は、UPS (uninterruptible power supply system 無停電電源装置) の設置について話しています。私たちは自動車サイズのUPSとコンテナサイズのオートスタート式の発電機を社内に持っています。しかしまだ、私は大規模インストールに関して、データベースの整合性をUPS等に頼ることはありません。つまり、電源以外の多くのことは上手くいかないのです。データ保存のプロセスに問題がある場合、ユーザに報告することが正しい判断です。async (非同期) 書き込みでは、データキューがまだ保存されていないことが結末となりますが、あなはたすでにユーザに対して、そのことを伝えているのです。

これはデータベースがやることではありません。

現在、私はlivejournalおよびslashdotで使用されている、いくつかの似たようなテクニックを調査しています。データベースロードを50%下げることで、私たちはMoodleのスケーラビリティを増強することができます。これは緊急のプロジェクトの間を縫って、緩やかに進行しています。もし、この内容に興味をお持ちでしたら、リチャード (Richard ) または私にご連絡 (ping) ください。

===関連情報===
* [http://docs.moodle.org/en/Step-by-step_Install_Guide_for_Ubuntu#Install_Postgresql_.28skip_MySQL.29 Installing Postgres on Ubuntu(Debian)]

[[Category:管理者]]
[[Category:パフォーマンス]]

[[en:Arguments_in_favour_of_PostgreSQL]]