greenplum进行全磁盘扫描有哪些优势？

Question

我们知道，GPDB通过给定的哈希键将数据库项目分布到几个段中。我确信它可以为条件查询提供更好的性能，尤其是对于那些具有给定分布式键/字段的查询，因为它可以极大地缩小扫描范围。

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

因此，所有段均被完全扫描，并且查询结果将通过网络发送到主机进行汇总。我们可以从这种情况中受益吗？

Answer 1

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

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

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

Answer 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。