「PostgreSQLを使う理由」の版間の差分

提供:MoodleDocs
移動先:案内検索
編集の要約なし
編集の要約なし
 
(同じ利用者による、間の20版が非表示)
1行目: 1行目:
作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] 2008年1月22日 (火) 00:59 (CST)
Martin Langhoffは、'''PostgreSQLの使用'''をお勧めします。 (出典: [http://moodle.org/mod/forum/discuss.php?d=24831#121862 Moodle over webct and LNLS at Athabasca University?] フォーラム投稿)
 
Martin Langhoffは、'''PostgreSQLの使用'''をお勧めします。 (出典: [http://moodle.org/mod/forum/discuss.php?d=24831#121862 Moodle over webct and LNLS at Athabasca University?] forum posting)


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


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


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


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


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


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


MySQLクラスタがasync書き込みを使用することを考えれば、read/writeをマスターおよびスレーブ間で分割して
MySQLクラスタがasync (非同期) 書き込みを使用することを前提として、私たちがデータを書き込んだ後、そのデータを即座 (または直後) に読み込む場合でも、MySQLは万が一に備えて、読み込み/書き込み (read/write) をマスターおよびスレーブ間で分割しています。そして、この「データの書き込み直後に読み出す」ことは、相当数が発生すると予想されます。
Given that the MySQL cluster uses async writes, splitting read/writes between the master and the slaves breaks down in cases where we write some data, and read it back in immediately (or soon after). And this does happen in quite a few places.


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


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
極めて簡単に言えば、私のデータが安全にハードディスクに保存されたと保証されても、また、仮に論理的に保存されたと保証されたとしても、通常MySQLは非常にソリッド (solid 確かな、安定した) というわけではありません。MySQLクラスタに至っては、前もって、これ以上の保証はないとされています。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.
マイケル (Michael) は、UPS (uninterruptible power supply system 無停電電源装置) の設置について話しています。私たちは自動車サイズのUPSとコンテナサイズのオートスタート式の発電機を社内に持っています。しかしまだ、私は大規模インストールに関して、データベースの整合性をUPS等に頼ることはありません。つまり、電源以外の多くのことは上手くいかないのです。データ保存のプロセスに問題がある場合、ユーザに報告することが正しい判断です。async (非同期) 書き込みでは、データキューがまだ保存されていないことが結末となりますが、あなはたすでにユーザに対して、そのことを伝えているのです。


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


===関連情報===
===関連情報===

2008年2月7日 (木) 14:41時点における最新版

Martin Langhoffは、PostgreSQLの使用をお勧めします。 (出典: 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ではSlonyを使用することができ、スレーブにおけるデータの整合性がさらに保証されます。

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

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

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

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

関連情報