5000 人以上のユーザーをサポートする Web アプリでは、postgres がボトルネックになりつつあります。
新しいユーザーを追加するのに 1 分以上かかります (最適化後でも Win 2k3 でも)。
では、設計上の問題として、他にどの DB が優れているでしょうか?
2378 次
12 に答える
49
ほとんどの場合、それは PostgreSQL ではなく、あなたの設計です。靴を変えても、より良いダンサーになることはほとんどありません。
速度低下の原因を知っていますか? 競合、インデックスの更新時間、シーク時間ですか? 5001 番目のユーザーを挿入しようとしているのとまったく同じ時刻に、5000 人のユーザー全員がユーザー テーブルに書き込もうとしていますか? それは、問題を引き起こす可能性があると私は信じています。Oracle のように、極端な同時実行性を処理するように調整されたものを使用する必要がある場合があります。
MySQL (聞いたところ) は PostgreSQL よりも高速な読み取りを行うように最適化できますが、どちらもサポートする # トランザクション/秒の点で非常に高速であり、それが問題ではないように思えます。
PS別の回答へのコメントで少し議論していました-世界最大のストレージに関するデータベースのいくつかはPostgresを使用して実装されていることに注意してください（ただし、エンジンの内部を微調整する傾向があります）. Postgres は、データ サイズに合わせて非常にうまくスケーリングし、同時実行性についてはほとんどの場合よりも優れており、それでできることに関して非常に柔軟です。
テクノロジーが発明されてから 30 年が経過した今、ユーザーがシステムをスムーズに実行できるようにするために、システムに関する詳細な知識を減らすことができるはずです。しかし残念なことに、私が知っているすべての製品には、広範な思考と微調整が必要です。StackOverflow の作成者は、データベースの同時実行性とスケーラビリティをどのように処理したかを共有できますか? 彼らは SQLServer を使用しています。私はそのことをよく知っています。
PPS 偶然にも、私は昨日、Oracle の同時実行性の問題に真っ向からぶつかりました。私は DBA ではないので、それが正しいかどうかは完全にはわかりませんが、彼らが説明したのは次のようなものでした: DB に接続してシステム辞書を調べる多数のプロセスがあったため、明らかに短いロックが強制されました。 、それはただの読み物であるという事実にもかかわらず。クエリの解析も同じことを行います..そのため、(数千のオブジェクトを持つマルチテラ システムでは) プロセスがシステムから互いにロックアウトしていたため、多くの強制的な待機時間がありました。また、システム ディクショナリは、各パーティションのすべての情報の個別のコピーが含まれているため、非常に大きくなりました。テーブルごとに数千の情報が存在する可能性があります。これは実際には PostgreSQL とは関係ありませんが、重要なのは、設計のチェックに加えて、
于 2008-10-15T16:15:47.950 に答える
9
Postgres を実行する OS を変更してください。Windows への移植は、ユーザー ベースの拡大には非常に役立ちますが、まだ(はるかに古く、より成熟した) Un*x への移植 (特に Linux の移植) と同等ではありません。
于 2008-10-15T19:29:36.250 に答える
5
あなたの最良の選択は依然として PostgresSQL だと思います。時間をかけて、アプリケーションを適切に調整してください。チューニングでできることの限界に達したと確信したら、できることすべてをキャッシュし始めます。その後、非同期マスター スレーブ セットアップへの移行を検討し始めます...また、OLTP を実行しているのと同じデータベースで OLAP タイプの機能を実行していますか?
于 2008-10-15T16:15:35.797 に答える
5
データベース設計が本当に最適である場合に、ほぼすべてのデータベース サーバーをスケーリングするための最も簡単で実用的な方法を紹介しましょう。RAM を 2 倍にするだけで、パフォーマンスが瞬時に向上します。それは魔法のようです。
于 2008-10-15T17:15:27.500 に答える
3
PostgreSQL はほとんどのデータベースよりもスケーリングに優れています。リレーショナル データベースを使用する場合は、Oracle が適しています。ODBMSは拡張性に優れていますが、設定するのがプログラミングに近いという点で、独自の問題があります。
Yahoo はPostgreSQLを使用しています。これは、スケーラビリティについて何かを教えてくれるはずです。
于 2008-10-15T16:14:55.703 に答える
2
上で強調したように、問題は使用している特定のデータベース、つまり PostgreSQL ではなく、次のいずれかです。
- スキーマの設計。インデックスの追加、削除、改良が必要になる場合があります
- ハードウェアは、サーバーの多くに要求している可能性があります-5,000 ユーザーと言いましたが、おそらく同時にデータベースにクエリを実行しているユーザーはほとんどいません
- クエリ: おそらく不十分に定義されているため、多くの非効率性が生じています
何が起こっているかを知るための実際的な方法は、PostgeSQL ログ ファイルを分析し、次の観点からどのようなクエリかを見つけることです。
- 最も頻繁に実行される
- 最長実行時間
- などなど
簡単なレビューにより、どこに力を注ぐべきかがわかり、問題をかなり迅速に解決できる可能性が高くなります。特効薬はありません。いくつかの宿題をしなければなりませんが、これはデータベース ベンダーを変更する場合に比べれば小さいものです。
朗報です...ログファイルを分析するための、使いやすく、解釈しやすい結果を生成するためのユーティリティがたくさんあります。
于 2010-03-26T10:34:37.610 に答える
1
こんにちは、以前に私の現在の会社で同じ問題がありました。私が最初に参加したとき、彼らのクエリは巨大で非常に遅かったです。それらを実行するのに 10 分かかります。数ミリ秒または 1 ～ 2 秒に最適化できました。その間に多くのことを学びました。その中のいくつかのハイライトを共有します。
最初にクエリを確認してください。必要なすべてのテーブルの内部結合を行うには、常に時間がかかります。私が提案することの 1 つは、実際にデータを必要なデータに切り分けることができるテーブルから常に開始することです。
例 SELECT * FROM (SELECT * FROM person WHERE person ilike '%abc') AS person;
上記の例を見ると、これにより結果が必要なことがわかっているものにカットされ、内部結合を行うことでそれらをさらに絞り込むことができます。これはクエリを高速化するための最良の方法の 1 つですが、猫の皮を剥ぐ方法は複数あります。数が多すぎるため、ここですべてを説明することはできませんが、上記の例から、必要に応じて変更する必要があります。
postgres のバージョンによって異なります。古い postgres はクエリを内部的に最適化します。たとえば、postgres 8.2 以下では、IN ステートメントは 8.4 よりも遅くなります。
EXPLAIN ANALYZE はあなたの友達です。クエリの実行速度が遅い場合は、Explain Analyze を実行して、速度低下の原因となっているクエリを特定します。
データベースをバキュームします。これにより、データベースの統計が実際の結果とほぼ一致することが保証されます。統計と実際の大きな違いにより、クエリの実行が遅くなります。
これらすべてが役に立たない場合は、postgresql.conf を変更してみてください。共有メモリを増やして、ニーズに合わせて構成を試してみてください。
これがお役に立てば幸いですが、もちろん、これらは postgres の最適化のためだけのものです。
ところで。5000 ユーザーは多くありません。私のDBには、約20万から100万のユーザーを持つユーザーが含まれています。
于 2010-09-27T14:42:41.150 に答える
1
まず、最適化が実際に役立つことを確認します。たとえば、多数のインデックスがある場合、レコードの追加または変更に時間がかかることがあります。PostgreSQL で実行されているいくつかの大きなプロジェクトがあることを知っているので、この問題を見てください。
于 2008-10-15T16:11:35.273 に答える
1
PostgreSQL のパフォーマンスに関する情報については、こちらを参照することをお勧めします。
実行している PG のバージョンは何ですか? リリースが進むにつれて、パフォーマンスは大幅に向上しました。
于 2008-10-15T16:15:13.880 に答える
0
書き込みに対する読み取りが多い場合は、問題がPostgresにあると想定して、MySQLを試してみることをお勧めしますが、問題は書き込みの問題です。
それでも、データベースの設計を調べて、シャーディングを検討することをお勧めします。非常に大規模なデータベースの場合でも、上記の2つの問題を確認する必要がある場合があります。
また、手元のタスクに応じて、非RDBMSデータベースサーバーまたはMensiaやCouchDBのようなドキュメント指向を確認することもできます。単一のツールですべてのタスクを管理することはできないため、賢明に選択してください。
好奇心から、この遅延を引き起こしている可能性のあるストアドプロシージャはありますか？
于 2008-11-26T23:23:05.773 に答える
0
詳細が必要です：使用しているバージョンは何ですか？サーバーのメモリ使用量はどれくらいですか？データベースをバキュームしていますか？パフォーマンスの問題はPostgreSQLとは関係がない可能性があります。
于 2008-10-18T13:19:49.037 に答える
0
PostgreSQL からの切り替えを希望する場合、Sybase SQL Anywhere はTPC-C ベンチマーク リストで価格/パフォーマンスの点で 5 位です。また、トップ 10 リストの中で (圧倒的に) 最低価格のオプションであり、Microsoft および Oracle 以外の唯一のエントリです。
数千人のユーザーと数テラバイトのデータに簡単に拡張できます。
完全な開示: 私は SQL Anywhere 開発チームで働いています。
于 2008-10-15T16:45:28.763 に答える