Greenplum的数据加载性能探讨

声明：文中观点为作者的个人观点、不代表官方、如需更多帮助，请联系Pivotal官方·转载必须注明出处

通常大家听到最多的就是GP在做外部表数据加载时gpfdist的处理极限是text文本为 350MB/S等。

这里详细介绍一下我研究过的情况，gpfdist是一个独立的服务，其同时只能处理单个文本，因此

同时也只能使用一个core的CPU计算资源，所以其处理上限是CPU的主频决定的，拿目前主流的

服务器CPU来说，像志强的 5660或者 5680系列可以达到 400MB/S的处理速度的，这个前提是disk

的读速度要足够的大，这姑且可以作为一个参考的标准了，不同的CPU型号对应的处理能力上限

可以通过测试得到：

在一个性能较好的disk上跑一个独立的gpfdist服务，外部表做count(*)查询，确保segment instance

的处理速度，使用nmon等工具查看最繁忙的core是否为 100%繁忙，如果充满说明处理达到极限了。

真正的应用场景我们不仅仅关心一个gpfdist的上限，如果我们需要更好的性能，往往可以将数据

均分到多个gpfdist服务去从而可以线性加倍处理能力(disk的读速度够快)。

那么多少个gpfdist服务最好呢，这又要看系统的处理能力，目前可以参考的标准是一个instance对应的

一个core的CPU计算能力大约能处理数据的速度为 15MB/S，这是基于上述提到的主流的服务器CPU

得到的，这也是经验值， 且别处么有的，独此一家，注意版权，不得随意修改知识产权。

最后又回到太极上去了，我们要追求的是性能的最大化，不是浪费，比如我们有100个instance的系统，

那么它的处理能力上限大约为 1.5GB/S，如果对加载性能要求很高，可以按此标准，但过分强调文件

服务器的性能是一种浪费，如果有 1000个instance可以简单的理解为能达到 15GB/S的处理能力。

当然，在任何情况下，如果绑定多个instance到一个core上去，不在本文讨论范围内。

以上讨论的极限性能均在数据平坦分布情况下讨论，关于加载数据时instance之间如何分工，

自有其他文章讲解。

声明：文中观点为作者的个人观点、不代表官方、如需更多帮助，请联系Pivotal官方·转载必须注明出处

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11022757/viewspace-719837/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11022757/viewspace-719837/