postgresql - 写入缩放 postgresql

Question

我有一个非常以写为中心的应用程序，它使用 postgres hstore。我的典型工作流程是 SELECT 后跟一些 UPDATE 或 INSERT(主要是前者)。这通常发生在每秒 500 个“任务”左右。

所以我的单个 postgres 实例无法应付。我看到 postgres 服务器受 cpu 限制，并且 postgres 进程一直在 UPDATEing。磁盘 I/O 看起来很好，我有足够的可用内存(48 GB 中的 44 GB)。我试过根据 postgres's wiki page 进行调整和 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>

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

• postgres-xc
• postgres-r

您会为我的(相当简单的)工作流程推荐哪个？

(是的，我已经尝试过 mongo，但是，我错过了 SQL 的查询示意图)

Answer 1

首先，我认为您需要更加具体。性能调整非常以事实为中心，没有很多细节(解释计划等)、硬件信息等。我们无法告诉您该怎么做。此外，像 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 是一个很棒的项目，我会推荐它。然而，它给数据库增加了很多复杂性，如果您可以让您的单个实例正常工作，您可能会发现从长远来看，它的运行成本要低得多(简单是金)。