7

我找到了大量关于如何为 OLTP 应用程序调整和优化 Postgres 性能的在线和打印指南,但我还没有找到任何特定于数据仓库应用程序的内容。由于工作负载的类型存在如此多的差异,我确信在管理和调整数据库的方式上肯定存在一些差异。

我自己的一些:

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

  • 对于通常具有多个自然键的数据,我通常会使用整数代理键来实现更快的连接

  • 我通常会定义和维护一个非常全面的日期表,该表具有预先构建的日期操作(会计日期而不是日历日期、财政年度月份、一周的开始日期等)并自由使用它而不是在 select 语句中使用函数和 where 语句。这通常在受 CPU 限制的聚合查询期间有所帮助。

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

4

2 回答 2

2

我的经验(诚然,在数据仓库方面规模很小):

  • 就像您提到的那样,预聚合数据很容易成为最重要的事情,因为它将需要读取的数据量减少了许多数量级。
  • 避免短写事务、子事务和保存点。这包括 PL/pgSQL 中的异常处理。这些会快速消耗可用的“事务 ID”空间,并导致需要重写整个表的昂贵的“环绕”真空
  • 我发现分区表使得每个分区都可以单独放入内核的缓存中,这对于维护和迁移很有好处,如果你需要做任何事情的话。这意味着您可以在一个分区上重新创建所有索引,只需从磁盘进行 1 次 seq 扫描,而不是对每个索引进行一次扫描。
  • 就像 Chris 已经提到的,对 work_mem 和 maintenance_work_mem 大方一些;如果您的工作负载不适合 RAM,那么由于更智能的查询计划(最重要的是 HashAggregate),在内存中保留更多临时数据可以节省 I/O 和 CPU 时间。
  • 如果您需要做大量工作,购买专用 SSD 来存储临时文件会有所帮助。
于 2014-04-14T13:07:27.377 回答
1

从内存管理的角度来看,您最大的区别之一是您通常希望将工作的 OLTP 设置保留在内存中,而 OLAP 环境并非如此。此外,您的连接集通常更大。这意味着更高的 work_mem 设置可能非常有用,并且在表非规范化的范围内,这意味着可以将 work_mem 推高一点。我不确定我对 shared_buffers 的建议是否会改变(我更喜欢从低位开始并增加,在每一步测试性能),但如果您正在报告任何大小的集合,work_mem 肯定需要增加。

于 2013-03-22T02:14:54.393 回答