跳至主要內容

Klustron对比社区版PostgreSQL之PostGIS性能及扩展性测试

Klustron大约 6 分钟

Klustron对比社区版PostgreSQL之PostGIS性能及扩展性测试

Klustron数据库是存算分离的分布式架构,相比于普通的社区版PostgrSQL数据库,拥有更好的弹性计算性能和扩展性,本文通过使用网上公开的纽约出租车数据,将其分别装载到Klustron环境和社区版PostgreSQL环境,运行一些典型的分析型SQL,获得性能对比结论。

另外,由于Klustron本身的架构支持计算性能的水平扩展,所以,在业务需要时,可以灵活方便的水平扩展计算能力和存储容量,相比于社区版PostgreSQL只能单体垂直扩充单机的做法,在整体吞吐能力和存储容量上有绝对的优势。

PostGIS是PostgreSQL社区最知名的功能扩展之一,其历史和知名度与PostgreSQL相当,在GIS数据管理领域基本上是最广泛使用的事实标准。

泽拓昆仑Klustron从1.3版本开始,支持了PostGIS扩展,用户可以用与挂载PostGIS到PostgreSQL完全相同的方法,把PostGIS挂载到Klustron的计算节点,来使用PostGIS的所有功能。这就让Klustron成为了一个分布式的PostGIS数据库,这极大地放大了PostGIS的GIS数据管理和计算能力,特别是考虑到GIS数据的计算(空间位置关系判别,以及空间对象的计算和生成)的计算量远远大于数值、字符串等简单数据类型,如果使用PostgreSQL挂载PostGIS的话,单台服务器的计算资源很容易成为严重的性能瓶颈。而Klustron分布式数据库可以使用上不封顶的计算资源,只要按需增加计算机服务器机器(这是最简单也是最低成本的操作)即可。

在实现层面,我们基于PostGIS-3.3.4,对其GIS数据存储读写略做修改,以便可以把GIS数据存储到Klustron的存储节点中。同时,我们做了大量细致的开发工作以便让PostGIS的空间计算函数可以下推到存储节点执行,以便通过并行化提升GIS查询性能,并且避免无用数据在计算节点和存储节点之间传递。

MySQL-8.0支持GIS数据存储和计算,并且自从MySQL-5.7开始,Oracle MySQL团队就重写了其GIS实现,使用boost.geometry作为GIS计算内核,在性能和准确性方面实现巨大提升。特别是MySQL-8.0支持了与PostGIS几乎完全相同的坐标系集合,因而广泛适用于全球各地的用户,他们可以使用本地坐标系系统,与使用PostGIS完全相同。所以,Klustron的PostGIS插件,在功能方面完全与PostgreSQL+PostGIS相同,在性能和可扩展性方面大大优于后者。

如下文所示,我们的实测表明,泽拓昆仑Klustron的PostGIS 在功能层面完全兼容PostGIS,而且性能也优于单机PostgreSQL挂载PostGIS的性能。

本文通过使用网上公开的纽约出租车数据,将其分别装载到Klustron环境和社区版PostgreSQL环境,运行一些典型的分析型SQL,获得性能对比结论。

01 测试环境

测试环境一: (Klustron)

节点类型IP端口
计算节点192.168.0.1947001
Shard1主节点192.168.0.2157007
Shard2主节点192.168.0.1957003
Shard3主节点192.168.0.2057005
XPanel192.168.0.1940180

运行环境,3台测试服务器配置相同:CentOS 8.5 Linux 64位,AMD Ryzen 9 7950X 16-Core(32线程), MEM: 128G, 存储:SSD 2T(M.2 SSD PCIE 4 固态)

PostGIS: 3.3.4

测试环境一: (PostgreSQL 11)

节点类型IP端口
单机192.168.0.215432

运行环境:CentOS 8.5 Linux 64位,AMD Ryzen 9 7950X 16-Core(32线程), MEM: 128G, 存储:SSD 2T(M.2 SSD PCIE 4 固态)

PostGIS: 3.3.5

02 性能对比

2.1 测试环境调优

为了确保测试过程中能发挥机器的资源配置性能及提升测试结果,我们在Klustron和PostgreSQL初始安装完成后,都对相关的参数做了适当的调整,如下所示:

Klustron:

计算节点:

shared_buffers='32GB';                       
statement_timeout=600000000;                 
mysql_read_timeout=360000;                   
mysql_write_timeout=360000;                  
mysql_interactive_timeout=360000;            
mysql_connect_timeout=100000;                
mysql_wait_timeout=360000;                   
lock_timeout=360000000;                      
log_min_duration_statement=120000000;        
effective_cache_size = '8GB';                
work_mem  = '1GB';                           
wal_buffers='64MB';                          
autovacuum=false;                            
metadata_connect_timeout=100000 ;            
metadata_read_timeout=100000 ;               
metadata_write_timeout=100000 ; 

存储节点:

innodb_buffer_pool_size=32*1024*1024*1024;   
lock_wait_timeout=3600;                      
innodb_lock_wait_timeout=3600;               
fullsync_timeout=1200000;                    
enable_fullsync=false;                       
innodb_flush_log_at_trx_commit=0;            
sync_binlog=0;                               
max_binlog_size=1*1024*1024*1024;            
net_read_timeout=3600 ;                      
net_write_timeout=3600 ;                     
thread_pool_queue_congest_req_timeout=3600 ; 
rocksdb_lock_wait_timeout=3600 ;             
delayed_insert_timeout=3600 ;                
connect_timeout=3600 ;                       
delayed_insert_timeout=3600 ;                
innodb_lock_wait_timeout=3600 ;              
mysqlx_connect_timeout=3600 ;                
mysqlx_read_timeout=3600 ;                   
mysqlx_write_timeout=3600 ;                  
mysqlx_wait_timeout=3600 ;  

说明:因测试条件有限,存储节点3个分片的备节点都与主节点共享了同样的机器,为消除资源争用的影响,3台测试机器上的存储备节点都已通过XPanel操作,实施了禁用。

PostgreSQL:

shared_buffers='32GB';                     
statement_timeout=600000000;            
lock_timeout=360000000;                    
log_min_duration_statement=120000000;      
effective_cache_size = '8GB';              
work_mem  = '1GB';                         
wal_buffers='64MB';                        
autovacuum=false;

2.2 测试数据准备:(NYC Taxi Data)

访问:https://github.com/toddwschneider/nyc-taxi-data/tree/master 此链接包含了纽约出租车数据的数据装载入库脚本,同时,脚本中也包含了数据下载的链接,按README的说明,对Klustron和PostgreSQL装载同等数量的数据(数据区间:2019-01至 2022-11),为测试做准备,数据准备情况如下:

Klustron:

因为Klustron存储有3个分片,故对trips表设计了64个分片,分区表的名字从trips_0至trips_65,数据均匀的分布在3个分片存储的64个分区中,总记录数为1.7亿多行,如下:

PostgreSQL:

因为该数据库为单机环境,故trips表不再设计分区,直接单表装载,数据情况如下:

备注:在测试之前,对两个环境中的trips表和及相关的分区已做分析,生成统计信息,确保优化器会生成最优的执行计划。

2.3 性能测试对比

Q1:  SELECT cab_type_id, count(*) FROM trips GROUP BY cab_type_id;

Q2:  SELECT passenger_count, avg(total_amount) FROM trips GROUP BY passenger_count;

Q3:  SELECT passenger_count, to_char(pickup_datetime,'yyyy-mm') AS month, count(*) FROM trips GROUP BY passenger_count, month;

Q4:  SELECT passenger_count, to_char(pickup_datetime,'yyyy-mm') AS month, round(trip_distance) AS distance, count(*) FROM trips GROUP BY passenger_count, month, distance ORDER BY month, count(*) DESC;

测试结果:

从上述测试结果可以看观察到,在初始简单的SQL测试中,Klustron与PostgreSQL并没有太大的性能差异,但随着SQL 复杂度的提升,Klustron分布式架构的性能明显发挥了作用,与社区版PostgreSQL拉开了明显的差距,可以推断,随着数据量的进一步上升和SQL复杂度的提升,Klustron将发挥比社区版PostgreSQL能存更多数据,跑得更快的优势。

END