PostgreSQL调整数据仓库的最佳实践

Question

我找到了大量有关如何调整和优化Postgres for OLTP应用程序性能的在线和打印指南，但我还没有找到任何特定于Data Warehousing应用程序的类型。由于工作负载类型存在很多差异，我确信在管理和调优数据库方面必须存在一些差异。

我自己的一些：

• 我从DDL方面发现我更自由地使用索引，因为我通常只担心每天插入一次并且可以使用索引重建进行批量插入。

• 我通常会将整数代理键用于通常具有多个自然键以加快连接速度的数据

• 我通常会定义并维护一个非常全面的日期表，该日期表具有预建日期操作（财务日期，而不是日历日期，会计年度月，一周的开始日期等）并且使用它而不是相反在select语句和where语句中使用函数。这通常有助于在CPU绑定的聚合查询期间。

我希望我能找到有关内存管理和其他数据库设置的一些信息，但我很高兴听到任何特定于基于Postgres的数据仓库的有用最佳实践。

Answer 1

我的经验（当然，数据仓库的规模相当小）：

• 就像你提到的那样，预聚合数据很容易是最重要的事情，因为它减少了需要读取数量级的数据量。
• 避免短写事务，子事务和保存点。这包括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来存储临时文件。

Answer 2

从内存管理的角度来看，您最大的区别之一是您通常希望将工作OLTP集保留在内存中，而OLAP环境则不然。此外，您的联合集通常更大。这意味着更高的work_mem设置可能非常有用，并且对于表的非规范化，这意味着可以将work_mem推得比其他情况更高一些。我不确定我对shared_buffers的建议是否会改变（我更喜欢从低位开始增加，在每一步测试性能）但是如果你正在报告任何大小的集合，那么work_mem当然需要增加。