greenplum 进行全盘扫描有啥优势？

Posted 2023-03-31

【中文标题】greenplum 进行全盘扫描有啥优势？

【英文标题】：What are the advantages of greenplum for full disk scan?greenplum 进行全盘扫描有什么优势？

【发布时间】：2019-04-15 01:58:38

【问题描述】：

正如我们所知，GPDB 通过给定的哈希键将数据库项分配到多个段中。我确信它会为条件查询提供更好的性能，特别是对于那些具有给定分布式键/字段的查询，因为它可以大大减少扫描范围。

但是全盘扫描呢？例如，select count(distinct aField) from table，或select aField, count(distinct bField) from table group by aField，...等等 - 无条件查询。

这样所有的segment都被全扫描了，查询结果会通过网络发送给master进行聚合。我们可以从这样的案例中得到什么好处？

【问题讨论】：

数据库查询不是“磁盘扫描”。请澄清您的要求。

“优势”与什么相比？

是的，全表扫描，不是磁盘扫描。 @斯蒂芬C

相比于将所有数据存储在一个 postgresql 数据库实例@Ancoron

@mik - 所以请更新问题说这个！使用“编辑”按钮。

【参考方案1】：

Greenplum 处理顺序扫描的速度非常快，并且由于您的数据分布在各个段中，这意味着小块数据正在由多个段并行扫描。

更不用说您可以使用正确的“行/列”方向方法来组织数据，这可能会导致要扫描的数据更小。

此外，如果您谈论的是海量数据，您可能会使用分区表，这意味着更快的结果。

【讨论】：

同意（假设是全表扫描，而不是磁盘，Stephen）。请记住按查询谓词进行分区——不要分发。如果您按查询谓词进行分区，则会减少每个段要扫描的数据量。如果您通过查询谓词进行分发，则会减少工作中活动的段数（处理偏差）。

@all: 引用？

@Ancoron here link，greenplum 文档对索引的解释，为这次讨论提供了一些启示，几乎完全符合我的回答。

非常感谢。 @布伦丹斯蒂芬斯

【参考方案2】：

由于 Greenplum 是 PostgreSQL 的一个分支，用于 parallel query execution at multiple segments - 如果实际查询的数据分布在它们之间 - 它基本上可以利用来自多个磁盘系统和单个节点缓存的更高执行性能。数据发送到主节点和最终查询处理的开销以及主节点必须准备每个节点的查询并将其发送下来进行处理的开销通常很小，但如果需要最终排序的非聚合查询会增加很多由主人完成。

然而，正如他们最近 merged in version 9.4 的上游 PostgreSQL 代码一样，Greenplums 的性能声明的主要问题是，它与一个太旧的 PostgreSQL 版本相比，对于任何关心性能并且没有从中受益的人来说从 9.6 版开始引入的parallel query 改进。

每个主机的多个段在这里也没有多大帮助，因为每个段对同一主机上的其他段一无所知，因此正在争夺资源（磁盘 I/O、内存操作、CPU 缓存、网络, ...) 或者你实际上必须limit it a lot per segment as recommended，这会让你发疯，因为一些查询然后只是溢出到磁盘进行排序。正确配置的单个 PostgreSQL 11 安装应该优于单个节点上任意数量的 Greenplum 段，这仅仅是因为它具有更多可用的总缓存并且它实际上知道它。

TL;DR

PostgreSQL 上游近年来得到了很多改进，对于特定用例，请考虑使用扩展而不是完整的 fork。

另外，如果您担心count(distinct ...) 的性能，您应该密切关注how you are counting。