寫縮放postgresql

Question

我有一個非常寫的使用postgres hstore的中心應用程序。我的典型工作流程是SELECT，然後是UPDATE s或INSERT s（主要是前者）。這通常發生在每秒約500個'任務'。

所以我的單個postgres實例無法應付。我看到postgres服務器是cpu綁定的，並且postgres進程始終是UPDATE。磁盤I/O顯示正常，我有大量的內存空間（44GB中的48）。我試過按照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 S的是類型：

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

在挖掘時，我發現，聲稱幫助兩個項目具有寫入性能：

• postgres-xc
• postgres-r

這將你推薦給我（相當簡單）的工作流程？

（是的，我已經試過蒙戈，但我錯過了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>類似的聲明，我稱之爲「baloney」，因爲在沒有更新數據時，可能沒有必要記錄更新的行。其他事情可能會在這裏發生。我的猜測是，你有很多查詢更新擴展存儲中的東西。這可能不是什麼大問題，因爲你不是I/O綁定的，但是它在CPU和磁盤I/O上都會產生開銷。

總的來說，Postgres-XC是一個很棒的項目，我會推薦它。但是它增加了很多數據庫的複雜性，如果你可以讓你的單一實例工作，你可能會發現從長遠來看，運行起來要便宜很多（簡單性很好）。