2

postgres hstore を使用する非常に書き込み中心のアプリケーションがあります。私の典型的なワークフローは、 a のSELECT後にいくつかのUPDATEs またはINSERTs が続きます (主に前者)。これは通常、1 秒あたり約 500 の「タスク」で発生します。

そのため、私の単一の postgres インスタンスでは対応できません。postgres サーバーが CPU バウンドであり、postgres プロセスがUPDATE常に実行されていることがわかります。ディスク I/O は正常に表示され、十分な空きメモリがあります (48 GB のうち 44 GB)。postgres の wiki ページと pg_tune に従ってチューニングを試みましたが、もう少しパフォーマンスが必要です。

私のテーブルは次のデザインに従っています:

   Column   |           Type           |                              Modifiers                              | Storage  | Stats target | Description
------------+--------------------------+---------------------------------------------------------------------+----------+--------------+-------------
 id         | integer                  | not null default nextval('table_id_seq'::regclass) | plain    |              |
 created_at | timestamp with time zone | not null                                                            | plain    |              |
 updated_at | timestamp with time zone | not null                                                            | plain    |              |
 context    | hstore                   | default hstore((ARRAY[]::character varying[])::text[])              | extended |              |
 data       | hstore                   | default hstore((ARRAY[]::character varying[])::text[])              | extended |              |

私のほとんどすべてのUPDATEタイプは次のとおりです。

UPDATE <table> updated_at=<date> WHERE id=<id>

掘り下げたところ、書き込みパフォーマンスに役立つと主張する2つのプロジェクトが見つかりました。

私の（かなり単純な）ワークフローにはどれをお勧めしますか?

(はい、mongo を試しましたが、SQL のクエリ スキーマが恋しいです)

4

1 に答える 1

4

まず、もっと具体的にする必要があると思います。パフォーマンス チューニングは非常に事実中心であり、多くの詳細 (計画の説明など) やハードウェアに関する情報などがなければ、どうすればよいかわかりません。さらに、Postgres-XC のようなものは、書き込みパフォーマンスには役立ちますが、複雑さが増します。あなたの場合には役立つと思いますが、最初に自分が持っているものを最適化したい (そして、最適化するために誰かを雇うかもしれません)。

ただし、あなたの投稿には警告サインがたくさんあります (これが、専門家を雇うのが良い考えだと思うもう 1 つの理由です)。詳細を知らなければ、Postgres-XC が適切なソリューションであるかどうかはわかりません。私が言えることは、それを実装するには急な学習曲線が必要だということです。

警告サインはチューニング ポイントの可能性を表しているので、それらを確認したいと思います。

  1. i see that the postgres server is cpu bound and the postgres processes are UPDATEing all the time. これは、セマフォと共有メモリの競合が多すぎることが原因である可能性があります。最大接続数を減らすと、1 秒あたりの処理量が増えることに気付くでしょう。接続プールが役立つ場合があります。

  2. 興味深いデータはすべて拡張ストレージにあります。これは、ストレージと検索で余分なランダム ディスク I/O が発生することを意味します。テーブルで多くの順次スキャンを実行していない限り、何を TOAST するかを PostgreSQL に決定させる必要があります。

  3. UPDATE <table> updated_at=<date> WHERE id=<id>データを更新していないときに行を更新済みとして記録する理由はおそらくほとんどないため、ほとんどのステートメントが似ているというあなたの主張について、私はばかげたことを呼びます。ここで何か他のことが起こっている可能性があります。私の推測では、拡張ストレージ内のものも更新するクエリがたくさんあると思います。I/O バウンドではないため、これはパフォーマンス面で大した問題ではないかもしれませんが、CPU とディスク I/O の両方でオーバーヘッドが発生します。

全体として、Postgres-XC は素晴らしいプロジェクトであり、私はそれをお勧めします。ただし、データベースに多くの複雑さが追加されます。単一のインスタンスを機能させることができれば、長期的に実行する方がはるかに安価であることがわかります (単純さは金です)。

于 2013-05-02T16:04:00.360 に答える