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 回答