使用PostgreSQL作为数据仓库 - narrator

banq

在人工智能公司Narrator支持许多数据仓库，包括Postgres。尽管它是为生产系统而设计的，但稍作调整后，Postgres可以非常好地用作数据仓库。  
总结：
  • 不要使用与生产系统相同的服务器
  • 升级到pg 12+（或在查询中避免使用通用表表达式）
  • 去容易对指标-少即是多
  • 考虑分区长表
  • 确保您不受I / O约束
  • 批量插入后进行真空分析
  • 探索并行查询
  • 增加统计抽样
  • 在经常查询的表上使用较少的列
  • 大规模考虑专门的仓库
 
数据仓库和关系数据库之间的差异
  • 生产查询OLTP
典型的生产数据库查询从潜在的大型数据集中选择几行。他们旨在快速回答许多这类问题。
想象一下一个Web应用程序–一次可能有成千上万的用户正在查询：
select * from users where id = 1234

数据库将被调整为快速（在毫秒内）处理大量此类请求。
为了支持这一点，大多数数据库（包括Postgres）都按行存储数据–这样可以有效地从磁盘加载整个行。他们经常使用索引来快速找到相对较少的行。
  • 分析查询OLAP
分析查询通常相反：
  • 查询将处理许多行（通常占整个表的很大一部分）
  • 查询可能需要几秒钟到几分钟才能完成
  • 查询将从一个宽（多列）表中的少数列中进行选择
因此，专用的数据仓库（如Redshift，BigQuery和Snowflake）使用面向列的存储，并且没有索引。
 
这对Po​​stgres意味着什么
尽管Postgres是面向行的，但它也可以轻松地用于分析查询。它只需要一些调整和一些测量。尽管Postgres是一个不错的选择，但请记住，从长远来看，像Snowflake这样的基于云的仓库将更易于管理和维护。
温馨提示：请勿将生产中Postgres实例同时用于数据报告/指标。可以进行一些查询，但是分析的工作负载与典型的生产工作负载相差甚远，以至于它们会对生产系统产生相当大的性能影响。

详细点击标题