2

我有一个非常以写为中心的应用程序，它使用 postgres hstore。我的典型工作流程是 aSELECT后跟多个UPDATEs 或INSERTs（主要是前者）。这通常以每秒约 500 个“任务”的速度发生。

所以我的单个 postgres 实例无法应付。我看到 postgres 服务器是 cpu 绑定的，并且 postgres 进程UPDATE一直在运行。磁盘 I/O 看起来很好，我有足够的可用内存（44GB，48GB）。我已经尝试按照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>

挖掘后，我发现了两个声称有助于提高写入性能的项目：

对于我的（相当简单的）工作流程，您会推荐哪个？

（是的，我尝试过 mongo，但是，我错过了 SQL 的查询示意图）

4

1 回答 1

4

首先，我认为您需要更加具体。性能调整非常以事实为中心，没有很多细节（解释计划等）、硬件信息等。我们无法告诉你该怎么做。此外，像 Postgres-XC 这样的东西增加了很多复杂性，尽管它确实有助于提高写入性能。我认为这对你的情况会有所帮助，但你真的想首先优化你拥有的东西（也许聘请某人为你优化它）。

但是，您的帖子中有很多警告标志（这是我认为聘请专业人士可能是个好主意的另一个原因）。在不了解更多信息的情况下，我无法告诉您 Postgres-XC 是否是正确的解决方案。我可以告诉你的是，你将有一个陡峭的学习曲线来实现它。

所以我想通过警告标志，因为它们代表可能的调整点。

  1. i see that the postgres server is cpu bound and the postgres processes are UPDATEing all the time. 这很可能是由于信号量和共享内存的争用过多造成的。您可能会发现，如果减少最大连接数，您每秒会处理更多。连接池可能会有所帮助。

  2. 您所有有趣的数据都在扩展存储中。这意味着存储和检索时额外的随机磁盘 I/O。除非您对表进行大量顺序扫描，否则您应该让 PostgreSQL 决定要 TOAST 的内容。

  3. 我称您声称大多数语句都是一样UPDATE <table> updated_at=<date> WHERE id=<id>的，因为当您不更新数据时，可能几乎没有理由将行记录为已更新。这里可能还会发生其他事情。我的猜测是，您也有很多查询更新扩展存储中的内容。这在性能方面可能没什么大不了的，因为您不受 I/O 限制，但它确实会产生 CPU 和磁盘 I/O 的开销。

总的来说，Postgres-XC 是一个很棒的项目，我会推荐它。然而，它给数据库增加了很多复杂性，如果你可以让你的单个实例工作，你可能会发现从长远来看运行起来要便宜得多（简单是金）。

于 2013-05-02T16:04:00.360 回答