一、为什么要集群？
1.JavaEE项目，如果部署在一台Tomcat上，所有的请求，都由这一台服务器处理，存在很大风险：
A：并发处理能力有限
（一般单台服务器处理的并发量为250左右，超过250，可能会出现数据丢失，链接不稳定的情况）。因为单服务器的性能有限制。所以单台Tomcat的最大连接数有限制，
B：容错率低，一旦服务器故障，整个服务就无法访问了。
eBay于 1999年6月停机22小时的事故，中断了约230万的拍卖，使eBay的股票下降了9.2个百分点。
C：单台服务器计算能力低，无法完成复杂的海量数据计算。
提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能，于是出现了向量机，对称多处理机(SMP)等。但是当CPU的个数超过某一阈值，这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反，集群系统的性能随着CPU个数的增加几乎是线性变化的。
使用集群架构完成工作主要有以下几点决定：
1、高性能计算
一些国家重要的计算密集型应用（如天气预报，核试验模拟等），需要计算机有很强的运算处理能力⌄以全世界现有的技术，即使是大型机器，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务，便使用了计算机集群技术，集中几十上百台，甚至成千上万台计算机进行计算。
2、价格有效性
早期的淘宝，支付宝的数据库等核心系统就是使用上百万元的小型机服务器。后因使用维护成本太高以及扩展设备费用成几何级数翻倍，甚至成为扩展瓶颈，人员维护也十分困难，最终使用PC服务器集群替换之，比如，把数据库系统从小机结合Oracle数据库迁移到MySQL开源数据库结合PC服务器上来。不但成本下降了，扩展和维护也更容易了。
3、可伸缩性
当服务负载，压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。
通常情况下，硬件设备若想扩展性能，不得不增加新的CPU和存储器设备，如果加不上去了，就不得不购买更高性能的服务器，就拿我们现在的服务器来讲，可以增加的设备总是有限的。如果采用集群技术，则只需要将新的单个服务器加入现有集群架构中即可，从访问的客户角度来看，系统服务无论是连续性还是性能上都几乎没有变化，系统在不知不觉中完成了升级，加大了访问能力，轻松地实现了扩展。集群系统中的节点数目可以增长到几千乃至上万个，其伸缩性远超过单台超级计算机。
4、高可用性
单一的计算机系统总会面临设备损毁的问题，如CPU，内存，主板，电源，硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件还是会发生故障，但整个系统的服务可以是7*24小时可用的。
集群架构技术可以使得系统在若干硬件设备故障发生时仍可以继续工作，这样就将系统的停机时间减少到了最小。集群系统在提高系统可靠性的同时，也大大减小了系统故障带来的业务损失，目前几乎100%的互联网网站都要求7*24小时提供服务。
5、透明性
多个独立计算机组成的松耦合集群系统构成一个虚拟服务器。用户或客户端程序访问集群系统时，就像访问一台高性能，高可用的服务器一样，集群中一部分服务器的上线，下线不会中断整个系统服务，这对用户也是透明的。
6、可管理性
整个系统可能在物理上很大，但其实容易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用。
7、可编程性
在集群系统上，容易开发及修改各类应用程序。
蓝海大脑水冷工作站超融合架构承担着计算资源池和分布式存储资源池的作用，极大地简化了数据中心的基础架构，通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力。通过简单方便的统一管理界面，实现对数据中心计算、存储、网络、虚拟化等资源的统一监控、管理和运维。
型号 蓝海大脑水冷服务器
英特尔
处理器 Intel Xeon Gold 6240R 24C/48T,2.4GHz,35.75MB,DDR4 2933,Turbo,HT,165W.1TB
Intel Xeon Gold 6258R 28C/56T,2.7GHz,38.55MB,DDR4 2933,Turbo,HT,205W.1TB
Intel Xeon W-3265 24C/48T 2.7GHz 33MB 205W DDR4 2933 1TB
Intel Xeon Platinum 8280 28C/56T 2.7GHz 38.5MB,DDR4 2933,Turbo,HT 205W 1TB
Intel Xeon Platinum 9242 48C/96T 3.8GHz 71.5MB L2,DDR4 3200,HT 350W 1TB
Intel Xeon Platinum 9282 56C/112T 3.8GHz 71.5MB L2,DDR4 3200,HT 400W 1TB
AMD
处理器 AMD锐龙Threadripper Pro 3945WX 4.0GHz/12核/64M/3200/280W
AMD锐龙Threadripper Pro 3955WX 3.9GHz/16核/64M/3200/280W
AMD锐龙Threadripper Pro 3975WX 3.5GHz/32核/128M/3200/280W
AMD锐龙Threadripper Pro 3995WX 2.7GHz/64核/256M/3200/280W
AMD锐龙Threadripper Pro 5945WX 4.1G 12核/64M/3200/280W
AMD锐龙Threadripper Pro 5955WX 4.0G 16核/64M/3200/280W
AMD锐龙Threadripper Pro 5965WX 3.8G 24核/128M/3200/280W
AMD锐龙Threadripper Pro 5975WX 3.6G 32核/128M/3200/280W
AMD锐龙Threadripper Pro 5995WX 2.7G 64核/256M/3200/280W
显卡 NVIDIA A100×4, NVIDIA GV100×4
NVIDIA RTX 3090×4, NVIDIA RTX 3090TI×4,
NVIDIA RTX 8000×4, NVIDIA RTX A6000×4,
NVIDIA Quadro P2000×4,NVIDIA Quadro P2200×4
硬盘 NVMe.2 SSD: 512GB，1TB； M.2 PCIe - Solid State Drive (SSD),
SATA SSD: 1024TB, 2048TB, 5120TB
SAS:10000rpm&15000rpm,600GB,1.2TGB,1.8TB
HDD : 1TB，2TB,4TB,6TB,10TB
外形规格 立式机箱
210尺寸mm（高*深*宽) : 726 x 616 x 266
210A尺寸mm（高*深*宽) : 666 x 626 x 290
210B尺寸mm（高*深*宽) : 697 x 692 x 306
声卡：7.1通道田声卡
机柜安装 : 前置机柜面板或倒轨（可选）
电源 功率 : 1300W×22000W×1
软件环境 可预装 CUDA、Driver、Cudnn、NCCL、TensorRT、Python、Opencv 等底层加速库、选装 Tensorflow、Caffe、Pytorch、MXnet 等深度学习框架。
前置接口 USB3.2 GEN2 Type-C×4
指承灯电和硬盘LED
灵动扩展区 : 29合1读卡器，eSATA，1394，PCIe接口（可选）
读卡器 : 9合1SD读卡器（可选）
模拟音频 : 立体声、麦克风
后置接口 PS2接口 : 可选
串行接口 : 可选
USB3.2 GEN2 Type-C×2
网络接口 : 双万兆 (RJ45)
IEEE 1394 : 扩展卡口
模拟音频 : 集成声卡 3口
连接线 专用屏蔽电缆（信号电缆和电源电缆）
资料袋 使用手册、光盘1张、机械键盘、鼠标、装箱单、产品合格证等
服务器集群：服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡：
负载均衡
（Load
Balancing）
建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器：
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。
纯手工打字，希望可以帮的到你！
最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。
整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。
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。综合来看，我们选择了 开源版本的6.16.2 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性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）内核参数优化
按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：
vm.swappiness=10
vm.zone_reclaim_mode = 0
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.dirty_background_ratio = 0 # See System Memory
vm.dirty_ratio = 0
vm.dirty_background_bytes = 1610612736
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 3943084
vm.overcommit_memory=2
kernel.sem = 500 2048000 200 4096
4.集群部署步骤
1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。
2）配置用户，很常规的步骤
groupadd gpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3）配置sysctl.conf和资源配置
4）使用rpm模式安装
# yum install -y apr apr-util bzip2 krb5-devel zip
# rpm -ivh open-source-greenplum-db-6.16.2-rhel7-x86_64.rpm
5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作
6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件
gpssh-exkeys -f hostlist
7）较为复杂的一步是打包master的Greenplum-db-6.16.2软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下
gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6.16.2.tar.gz =:/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/limits.conf的资源配置不足会在安装时有如下的警告：
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
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
#127.0.0.1 test-dbs-gp-128-230
xxxxx.128.238 test-dbs-gp-svr-128-238
xxxxx.128.239 test-dbs-gp-svr-128-239
其中127.0.0.1的这个配置在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=0.00..431.00 rows=1 width=8) (actual time=24792.916..24792.916 rows=1 loops=1)
-> Gather Motion 36:1 (slice1segments: 36) (cost=0.00..431.00 rows=1 width=1) (actual time=3.255..16489.394 rows=150000000 loops=1)
-> Seq Scan on customer (cost=0.00..431.00 rows=1 width=1) (actual time=0.780..1267.878 rows=4172607 loops=1)
Planning time: 4.466 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: 24832.611 ms
(9 rows)
Time: 24892.500 ms
性能较好的SQL执行计划：
# explain analyze select count(*)from customer
QUERY PLAN
Aggregate (cost=0.00..842.08 rows=1 width=8) (actual time=1519.311..1519.311 rows=1 loops=1)
-> Gather Motion 36:1 (slice1segments: 36) (cost=0.00..842.08 rows=1 width=8) (actual time=634.787..1519.214 rows=36 loops=1)
-> Aggregate (cost=0.00..842.08 rows=1 width=8) (actual time=1473.296..1473.296 rows=1 loops=1)
-> Seq Scan on customer (cost=0.00..834.33 rows=4166667 width=1) (actual time=0.758..438.319 rows=4172607 loops=1)
Planning time: 5.033 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: 1543.611 ms
(10 rows)
Time: 1549.324 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: 1235.801 ms
tpch_1t=# select count(*)from lineitem
count
------------
5999989709
(1 row)
Time: 10661.756 ms
2）6个物理节点，（6+6）*6
# select count(*)from customer
count
-----------
150000000
(1 row)
Time: 1346.833 ms
# select count(*)from lineitem
count
------------
5999989709
(1 row)
Time: 18145.092 ms
3）4个物理节点，（6+6）*4
# select count(*)from customer
count
-----------
150000000
(1 row)
Time: 1531.621 ms
# select count(*)from lineitem
count
------------
5999989709
(1 row)
Time: 25072.501 ms
4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。
在1T基准下的基准测试表现：
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）