区别就是RAID 和加载驱动
一、版本不同
1、完全安装：是一个良好的基础 *** 作系统。
2、服务器核心安装：是标准版之上的一个版本。
二、特点不同
1、完全安装：专门设计用来提高服务器基础设施的可靠性和灵活性，同时帮助节省时间并减少成本。
2、服务器核心安装： *** 作系统平台为关键业务工作负载提供更具成本效益且可靠的支持。
三、优势不同
1、完全安装：提供一个可在其上建立企业级虚拟化和可扩展解决方案的基础。
2、服务器核心安装：为虚拟化、节能和管理性提供创新功能，并且帮助移动的工作人员更容易地访问公司资源。
参考资料来源：百度百科-Windows Server 2008 R2
对于Windows下多数软件的安装，我们是通过执行该软件的安装程序(setupexe、installexe、软件文件名exe)，由安装程序负责具体的安装过程。
这个过程中，安装程序做的工作一是系统注册：把该软件的一些系统文件，复制或移动到 *** 作系统的有关系统目录中，实现与 *** 作系统的接口，便于 *** 作系统使用;二是将自身的程序文件、数据文件等复制到本软件的安装目录下，用于本软件的运行。
(1)PHP语言解释器软件的安装和配置
该软件没有安装程序，所以具体的安装过程需要用户来完成。不过过程也十分简单：解压缩该软件包至安装目的目录，将系统文件php4tsdll(PHP系统扩展函数库)和phpini(PHP配置文件)分别放到 *** 作系统目录下的相应的位置即可。
(2)Apache的安装和配置
大体经过安装->配置两大步骤完成。配置大体经过编辑配置文件->启动服务完成。
安装：其安装过程由其安装程序进行，启动安装程序后，按提示 *** 作即可。
配置目的：向Apache说明清楚PHP的有关情况，以便实现二者的协作。
配置方法：主要通过一个配置文件中有关参数的修改或添加进行。所谓“修改”，即对该文件中已经存在的参数，修改其参数值;所谓“添加”，即将该文件中缺少的参数和参数值增加到该文件中相应位置，为了省事，也可以放到该文件的最后。该文件名为>Linux *** 作系统，是一种计算机 *** 作系统，中文读法大致为“里纳克斯”。Linux *** 作系统的内核的名字也是“Linux”。Linux *** 作系统也是自由软件和开放源代码发展中最著名的例子。
过去，Linux主要被用作服务器的 *** 作系统，但因它的廉价、灵活性及Unix背景使得它很合适作更广泛的应用。传统上有以Linux为基础的“LAMP（Linux, Apache, MySQL, Perl/PHP/Python的组合）”经典技术组合，提供了包括 *** 作系统、数据库、网站服务器、动态网页的一整套网站架设支持。而面向更大规模级别的领域中，如数据库中的Oracle、DB2、PostgreSQL，以及用于Apache的Tomcat JSP等都已经在Linux上有了很好的应用样本。除了已在开发者群体中广泛流行，它亦是现时提供网站务供应商最常使用的平台。
基于其低廉成本与高度可设定性，Linux常常被应用于嵌入式系统，例如机顶盒、移动电话及行动装置等。在移动电话上，Linux已经成为与Symbian OS、Windows Mobile系统并列的三大智能手机 *** 作系统之一；而在移动装置上，则成为Windows CE与Palm OS外之另一个选择。目前流行的TiVo数位摄影机使用了经过客制化后的Linux。此外，有不少硬件式的网络防火墙及路由器，例如部份LinkSys的产品，其内部都是使用Linux来驱动、并采用了 *** 作系统提供的防火墙及路由功能。
采用Linux的超级电脑亦愈来愈多，根据2005年11月号的TOP500超级电脑列表，现时世上最快速的两组超级电脑都是使用Linux作为其 *** 作系统。而在表列的500套系统里，采用Linux为 *** 作系统的，占了371组（即742%），其中的前十位者，有7组是使用Linux的。
从发展的背景看，Linux与其他 *** 作系统的区别是，Linux是从一个比较成熟的 *** 作系统发展而来的，而其他 *** 作系统，如Windows NT等，都是自成体系，无对应的相依托的 *** 作系统。这一区别使得Linux的用户能大大地从Unix团体贡献中获利。因为Unix是世界上使用最普遍、发展最成熟的 *** 作系统之一，它是七十年代中期发展起来的微机和巨型机的多任务系统，虽然有时接口比较混乱，并缺少相对集中的标准，但还是发展壮大成为了最广泛使用的 *** 作系统之一。无论是Unix的作者还是Unix的用户，都认为只有Unix才是一个真正的 *** 作系统，许多计算机系统（从个人计算机到超级计算机）都存在Unix版本，Unix的用户可以从很多方面得到支持和帮助。因此，Linux做为Unix的一个克隆，同样会得到相应的支持和帮助，直接拥有Unix在用户中建立的牢固的地位。
从使用费用上看，Linux与其他 *** 作系统的区别在于Linux是一种开放、免费的 *** 作系统，而其他 *** 作系统都是封闭的系统，需要有偿使用。这一区别使得我们能够不用花钱就能得到很多Linux的版本以及为其开发的应用软件。当我们访问Internet时，会发现几乎所有可用的自由软件都能够运行在Linux系统上。有来自很多软件商的多种Unix实现，Unix的开发、发展商以开放系统的方式推动其标准化，但却没有一个公司来控制这种设计。因此，任何一个软件商（或开拓者）都能在某种Unix实现中实现这些标准。OS/2和Windows NT等 *** 作系统是具有版权的产品，其接口和设计均由某一公司控制，而且只有这些公司才有权实现其设计，它们是在封闭的环境下发展的。
其实世界上的大多数科学家和工程师几乎用的都是 UNIX 作为他们的电脑工具。就因为它简单，可靠，稳定，强大，有趣。
要建立一个安全Linux服务器就首先要了解Linux环境下和网络服务相关的配置文件的含义及如何进行安全的配置。在Linux系统中，TCP/IP网络是通过若干个文本文件进行配置的，也许你需要编辑这些文件来完成联网工作，但是这些配置文件大都可以通过配置命令linuxconf (其中网络部分的配置可以通过netconf命令来实现)。下面介绍基本的 TCP/IP网络配置文件。
/etc/confmodules文件
该配置文件定义了各种需要在激活时加载的模块的参数信息。这里主要着重讨论关于网卡的配置。在使用Linux做网关的情况下，Linux服务器至少需要配置两块网卡。为了减少激活时可能出现的问题，Linux内核不会自动检测多个网卡。对于没有将网卡的驱动编译到内核而是作为模块动态加载的系统若需要安装多块网卡，应该在“confmodules”文件中进行相应的配置。
若设备驱动被编译为模块（内核的模块）：对于PCI设备，模块将自动检测到所有已经安装到系统上的设备；对于ISA卡，则需要向模块提供IO地址，以使模块知道在何处寻找该卡，这些信息在“/etc/confmodules”中提供。
例如，我们有两块ISA总线的3c509卡，一个IO地址是0x300，另一个是0x320。编辑“confmodules”文件如下：alias eth0 3c509alias eth1 3c509options 3c509 io=0x300，0x320这是说明3c509的驱动程序应当分别以eth0或eth1的名称被加载（alias eth0，eth1），并且它们应该以参数io=0x300，0x320被装载，来通知驱动程序到哪里去寻找网卡，其中0x是不可缺少的。
对于PCI卡，仅仅需要alias命令来使ethN和适当的驱动模块名关联，PCI卡的IO地址将会被自动的检测到。对于PCI卡，编辑“confmodules”文件如下：alias eth0 3c905alias eth1 3c905若驱动已经被编译进了内核：系统激活时的PCI检测程序将会自动找到所有相关的网卡。ISA卡一般也能够被自动检测到，但是在某些情况下，ISA卡仍然需要做下面的配置工作：
在“/etc/liloconf”中增加配置信息，其方法是通过LILO程序将激活参数信息传递给内核。对于ISA卡，编辑“liloconf”文件，增加如下内容：append=" ether="0，0，eth0 ether="0，0，eth1"注：先不要在“liloconf”中加入激活参数，测试一下你的ISA卡，若失败再使用激活参数。
如果用传递激活参数的方法，eth0和eth1将按照激活时被发现的顺序来设置。
/etc/HOSTNAME文件：
该文件包含了系统的主机名称，包括完全的域名，如：
deepopenarchcom
/etc/sysconfig/network-scripts/ifcfg-ethN文件：
在RedHat中，系统网络设备的配置文件保存在“/etc/sysconfig/network-scripts”目录下，ifcfg-eth0包含第一块网卡的配置信息，ifcfg-eth1包含第二块网卡的配置信息。
下面是“/etc/sysconfig/network-scripts/ifcfg-eth0”文件的示例：DEVICE=eth0IPADDR=2081641861NETMASK=2552552550NETWORK=2081641860BROADCAST=208164186255ONBOOT=yesBOOTPROTO=noneUSERCTL=no
若希望手工修改网络地址或在新的接口上增加新的网络界面，可以通过修改对应的文件（ifcfg-ethN）或创建新的文件来实现。
DEVICE=name name表示物理设备的名字
IPADDR=addr addr表示赋给该卡的IP地址
NETMASK=mask mask表示网络掩码
NETWORK=addr addr表示网络地址
BROADCAST=addr addr表示广播地址
ONBOOT=yes/no 激活时是否激活该卡
none：无须激活协议
bootp：使用bootp协议
dhcp：使用dhcp协议
USERCTL=yes/no 是否允许非root用户控制该设备
/etc/resolvconf文件：
该文件是由域名解析器（resolver，一个根据主机名解析IP地址的库）使用的配置文件，示例如下：
search openarchcomnameserver 2081641861nameserver 2081641862
“search domainnamecom”表示当提供了一个不包括完全域名的主机名时，在该主机名后添加domainnamecom的后缀；“nameserver”表示解析域名时使用该地址指定的主机为域名服务器。其中域名服务器是按照文件中出现的顺序来查询的。
共2页。
/etc/hostconf文件：
该文件指定如何解析主机名。Linux通过解析器库来获得主机名对应的IP地址。下面是一个“/etc/hostconf”的示例：
order bind，hosts
multi on
ospoof on
“order bind，hosts”指定主机名查询顺序，这里规定先使用DNS来解析域名，然后再查询“/etc/hosts”文件(也可以相反)。
“multi on”指定是否“/etc/hosts”文件中指定的主机可以有多个地址，拥有多个IP地址的主机一般称为多穴主机。
“nospoof on”指不允许对该服务器进行IP地址欺骗。IP欺骗是一种攻击系统安全的手段，通过把IP地址伪装成别的计算器，来取得其它计算器的信任。
/etc/sysconfig/network文件
该文件用来指定服务器上的网络配置信息，下面是一个示例：
NETWORK=yesRORWARD_IPV4=yesHOSTNAME=deepopenarchcomGAREWAY=0000GATEWAYDEV=NETWORK=yes/no 网络是否被配置；FORWARD_IPV4=yes/no 是否开启IP转发功能HOSTNAME=hostname hostname表示服务器的主机名GAREWAY=gw-ip gw-ip表示网络网关的IP地址GAREWAYDEV=gw-dev gw-dw表示网关的设备名，如：etho等
注意：为了和老的软件相兼容，“/etc/HOSTNAME”文件应该用和HOSTNAME=hostname相同的主机名。
/etc/hosts文件
当机器激活时，在可以查询DNS以前，机器需要查询一些主机名到IP地址的匹配。这些匹配信息存放在/etc/hosts文件中。在没有域名服务器情况下，系统上的所有网络程序都通过查询该文件来解析对应于某个主机名的IP地址。
下面是一个“/etc/hosts”文件的示例：
IP Address Hostname Alias127001 Localhost Gateopenarchcom2081641861 gateopenarchcom Gate
最左边一列是主机IP信息，中间一列是主机名。任何后面的列都是该主机的别名。一旦配置完机器的网络配置文件，应该重新激活网络以使修改生效。使用下面的命令来重新激活网络：/etc/rcd/initd/network restart
/etc/inetdconf文件
众所周知，作为服务器来说，服务端口开放越多，系统安全稳定性越难以保证。所以提供特定服务的服务器应该尽可能开放提供服务必不可少的端口，而将与服务器服务无关的服务关闭，比如：一台作为>
最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。
整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。
1集群架构改造的目标
在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：
1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。
2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。
3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。
4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。
5） *** 作系统版本升 级 ，之前的 *** 作系统是基于CentOS6，至少需要适配CentOS 7 。
6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。
此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。
2集群规划设计的选型和思考
明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：
1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6162 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。
2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。
3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）10+2，整体的配置情况类似下面的模式。
4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。
除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。
方案1 ：Master,Standby和segment混合部署
方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些
方案3 ：Segment独立部署，Master,Standby虚拟机部署
方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）
这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。
3集群架构的详细设计和实践
1）设计详细的部署架构图
在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。
2）内核参数优化
按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：
vmswappiness=10
vmzone_reclaim_mode = 0
vmdirty_expire_centisecs = 500
vmdirty_writeback_centisecs = 100
vmdirty_background_ratio = 0 # See System Memory
vmdirty_ratio = 0
vmdirty_background_bytes = 1610612736
vmdirty_bytes = 4294967296
vmmin_free_kbytes = 3943084
vmovercommit_memory=2
kernelsem = 500 2048000 200 4096
4集群部署步骤
1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。
2）配置用户，很常规的步骤
groupadd gpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3）配置sysctlconf和资源配置
4）使用rpm模式安装
# yum install -y apr apr-util bzip2 krb5-devel zip
# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm
5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量 *** 作
6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件
gpssh-exkeys -f hostlist
7）较为复杂的一步是打包master的Greenplum-db-6162软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下
gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/tmp
或者说在每台服务器上面直接rpm -ivh安装也可以。
8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。
mkdir -p /data1/gpdata/gpdatap1
mkdir -p /data1/gpdata/gpdatap2
mkdir -p /data2/gpdata/gpdatam1
mkdir -p /data2/gpdata/gpdatam2
9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。
10）部署GP集群最关键的命令是
gpinitsystem -c gpinitsystem_config -s standby_hostname
其中文件gpinitsystem_config的主要内容如下：
MASTER_HOSTNAME=xxxx
declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1 /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)
TRUSTED_SHELL=ssh
declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1 /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)
MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts
整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。
5集群部署问题梳理
集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：
1） 资源配置问题 ，如果/etc/security/limitsconf的资源配置不足会在安装时有如下的警告：
2） 网络问题 ，集群部署完成后可以正常 *** 作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count() from customer,但是会抛出如下的错误：
这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。
对于数据节点可以开放略大的权限，如：
入口的配置：
-A INPUT -p all -s xxxxx -j ACCEPT
出口的配置：
-A OUTPUT -p all -s xxxxx -j ACCEPT
3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count() from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。
为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。
gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp
$ cat /etc/hosts
127001 localhost localhostlocaldomain localhost4 localhost4localdomain4
::1 localhost localhostlocaldomain localhost6 localhost6localdomain6
#127001 test-dbs-gp-128-230
xxxxx128238 test-dbs-gp-svr-128-238
xxxxx128239 test-dbs-gp-svr-128-239
其中127001的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。
5集群故障恢复的测试
集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。
整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。
第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。
1）服务器宕机修复后集群恢复
select from gp_segment_configuration where status!='u';
gprecoverseg -o /recov
gprecoverseg -r
select from gp_segment_configuration where status='u'
2）服务器不可用时集群恢复
重构数据节点的过程中，总体来看网络带宽还是使用很充分的。
select from gp_segment_configuration where status='u'
select from gp_segment_configuration where status='u' and role!=preferred_role;
gprecoverseg -r
select from gp_segment_configuration where status='u' and role!=preferred_role;
经过测试，重启节点到数据修复，近50G数据耗时3分钟左右
6集群优化问题梳理
1）部署架构优化和迭代
对于优化问题，是本次测试中尤其关注，而且争议较多的部分。
首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。
数据集市的集群部分因为节点相对较少，所以就选用了第二套方案
实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。
所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。
这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。
在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。
所以经过对比后，还是选择了方案2的混合部署模式。
2）SQL性能优化的分析
此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。
在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。
性能较差的SQL执行计划：
# explain analyze select count()from customer;
QUERY PLAN
Aggregate (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)
-> Gather Motion 36:1 (slice1; segments: 36) (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)
-> Seq Scan on customer (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)
Planning time: 4466 ms
(slice0) Executor memory: 680K bytes
(slice1) Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0)
Memory used: 2457600kB
Optimizer: Pivotal Optimizer (GPORCA)
Execution time: 24832611 ms
(9 rows)
Time: 24892500 ms
性能较好的SQL执行计划：
# explain analyze select count()from customer;
QUERY PLAN
Aggregate (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)
-> Gather Motion 36:1 (slice1; segments: 36) (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)
-> Aggregate (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)
-> Seq Scan on customer (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)
Planning time: 5033 ms
(slice0) Executor memory: 176K bytes
(slice1) Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0)
Memory used: 2457600kB
Optimizer: Pivotal Optimizer (GPORCA)
Execution time: 1543611 ms
(10 rows)
Time: 1549324 ms
很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：
analyze customer;
但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。
3）集群配置优化
此外也做了一些集群配置层面的优化，比如对缓存做了调整。
gpconfig -c statement_mem -m 2457600 -v 2457600
gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000
7集群优化数据
最后来感受下集群的性能：
1）10个物理节点，（6+6）10+2
tpch_1t=# iming on
Timing is on
tpch_1t=# select count()from customer;
count
-----------
150000000
(1 row)
Time: 1235801 ms
tpch_1t=# select count()from lineitem;
count
------------
5999989709
(1 row)
Time: 10661756 ms
2）6个物理节点，（6+6）6
# select count()from customer;
count
-----------
150000000
(1 row)
Time: 1346833 ms
# select count()from lineitem;
count
------------
5999989709
(1 row)
Time: 18145092 ms
3）4个物理节点，（6+6）4
# select count()from customer;
count
-----------
150000000
(1 row)
Time: 1531621 ms
# select count()from lineitem;
count
------------
5999989709
(1 row)
Time: 25072501 ms
4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。
在1T基准下的基准测试表现：
物理服务器 （Physical Servers ）
指实实在在、存在的硬件专用独立主机或服务器设备，性能和稳定性都比较强，因此，价格也相对比较昂贵，需要用户自己根据需求进行配置、管理及运维。简单来说，物理服务器可以把它理解为一台“电脑”，实际上所有网站的程序都在这个“电脑”上运行。
云服务器 （Cloud Servers）
指通过虚拟化技术将一台独立服务器虚拟成多个小的服务器，每个云服务器的运行和管理都完全独立，具有单独的 *** 作系统，可分配独立公网IP地址、超大磁盘、 *** 作系统Windows/Linux、内存、CPU资源等，网站运行环境和空间安全都需要用户自己去配置，对用户的技术能力有一定要求的。
云服务器是云计算服务的重要组成部分，是面向各类互联网用户提供综合业务能力的服务平台。平台整合了传统意义上的互联网应用三大核心要素：计算、存储、网络，面向用户提供公用化的互联网基础设施服务。
物理服务器 VS 云服务器
成本优化
物理服务器而言，无论用还是不用，设备就在那里，成本就在那里，照样算钱！
云服务器遵循按需购买，按照使用量付费的原则，具有成本低、d性伸缩、管理便捷等特点。
服务优化
物理服务器服务常规指实体服务器托管和租用两种服务类型，实体服务器托管是由用户自行购买硬件发往机房托管，期间设备的监控和管理工作均由用户单方独立完成，IDC数据中心提供IP接入、带宽接入、电力供应和网络维护等，租用是由IDC数据中心租用实体设备给客户使用，同时负责环境的稳定，用户无需购买硬件设备；
云服务器服务是指是从基础设施(Iaas)到业务基础平台(PaaS)再到应用层(SaaS)的连续的整体的全套服务，IDC数据中心将规模化的硬件服务器整合虚拟到云端，为用户提供的是服务能力和IT效能。
相较传统IDC服务模式，云计算IDC增值服务是相关于传统IDC增值服务的升级，是云计算数据中心下对传统IDC服务的升级版！云计算IDC情况下，可获得具备高扩展性和高可用的计算能力，用户也再无需担心硬件设备的性能限制等带来的问题。
资源优化
物理服务器，在硬件服务器的基础进行有限的整合，例如多台虚拟机共享一台实体服务器性能。
云服务器可通过资源集约化实现的动态资源调配，云计算可以实现横向/纵向的d性资源扩展和快速调度，传统IDC提供的资源难以承受短时间内的快速再分配，且不说企业等待的时间成本，本身而言容易造成资源闲置和浪费！
云服务器而言，通过更新的技术实现资源的快速再分配，可以在数分钟甚至几十秒内分配资源实现快速可用，可以有效地规避资源闲置的风险。此外，传统IDC远不如云计算IDC那样可以跨实体服务器，甚至实现跨数据中心的大规模有效整合。
效率优化
云计算IDC服务相较传统IDC服务，前者采取更加灵活的资源利用方式，通过技术提升和优化使用户从硬件设备的管理和运维工作中解脱出来，专注内部业务的开发和创新，由云服务商负责云平台本身的稳定，通过这种责任分担模式使整个平台的运行效率获得提升！
售后优化
首先，云服务器归于基本电信增值服务，所以其服务提供商需要获得工信部的批阅以具有相应的运营资质。云服务商对国家方针政策的了解，备案等业务流程的支持，也是确保客户可以合法合规的运营。再者，当服务器使用过程出现问题时，需要运营商的协助才可以解决，这种情况需要任何时候都可以找到主机商的售后支持，大多数云服务商而言都会提供724小时的云服务器售后支持服务，这点也可以打消用户的使用顾虑，让用户安心、放心！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）