PostgreSQL調優數據倉庫的最佳實踐

我發現了大量關於如何調整和優化Postgres for OLTP應用程序性能的在線和打印指南，但是我沒有發現任何特定於數據倉庫應用程序的排序。由於工作負載類型之間存在如此多的差異，我相信在數據庫的管理和調整方面必須有一些差異。PostgreSQL調優數據倉庫的最佳實踐

一些我自己的：

我已經從我使用索引了很多更寬鬆的DDL側發現，因爲我通常只擔心刀片每天一次，並與索引重建可以做批量插入。
我通常會使用整數代理鍵通常有不止一個自然鍵快加入
我通常會定義和維護具有預建日期的操作（財政日期作爲一個非常全面的日期表數據與日曆日期，財年 - 月份，本週開始日期等相反），並自由使用它，而不是在select語句和where語句中使用函數。這通常有助於在CPU綁定的聚合查詢中。

我希望我會找到對內存管理和其他數據庫設置一些信息，但我會很樂意聽到的Postgres基於數據倉庫的任何有用的最好的具體做法。

來源

2012-09-04 dannytoone

對此沒有簡短的回答。如果您想了解有關優化PostgreSQL的一般信息，我可以推薦以下書籍：http：//www.packtpub。com/postgresql-90-high-performance/book（有免費的章節可用） – Eelke

讓我們知道你是否發現了一些有趣的信息。當我們在時間維和事實表中將'bigint'更改爲'smallint'時，我們得到了很大的性能改變。 –

我會推薦從Josh Berkus http://vimeo.com/9889075觀看這個優秀的演講「PostgreSQL性能的5個步驟」。這將回答你的很多問題，或者讓你接近自己回答。 – Will

從內存管理的角度來看，你最大的不同之處在於你可以經常希望將正在工作的OLTP集保留在內存中，而OLAP環境並非如此。另外很多時候你的加入的組合更大。這意味着更高的work_mem設置可能非常有用，並且在表格非規範化的情況下，這意味着可以將work_mem推高一點。我不確定我對shared_buffers的建議是否會發生變化（我傾向於從低開始增加，並在每個步驟測試性能），但如果您正在報告任意大小的集合，則work_mem肯定需要增加。

來源

2013-03-22 02:14:54

我的經驗（在一個非常小的規模無可否認，當涉及到數據倉庫）：

就像你提到的，預聚合數據無疑是最重要的事情，因爲它降低了數據量需要被讀取許多個數量級。
避免寫短交易，子事務和保存點。這包括PL/pgSQL中的異常處理。這些快速燒穿可用的「交易ID」空間，並導致expensive "wraparound" vacuums that need to rewrite whole tables。
我發現分區表使得每個分區都可以適應內核的緩存，這對於維護和遷移非常有用，如果您需要執行任何操作。這意味着您可以在磁盤上僅使用1 seq掃描來重新創建分區上的所有索引，而不是爲每個索引掃描一次。
就像克里斯已經提到的那樣，對work_mem和maintenance_work_mem慷慨;如果你的工作負載不適合RAM，那麼在內存中保存更多的臨時數據可以節省I/O和CPU時間，因爲更聰明的查詢計劃（最重要的是HashAggregate）。
如果您需要做大量的排序，它可以幫助購買專用的SSD來存儲臨時文件。

來源

2014-04-14 13:07:27 intgr

PostgreSQL調優數據倉庫的最佳實踐

回答

相關問題