1. 文章
  2. 架构及方案

Greenplum实现高性能大容量数据仓库之ScaleFlux卡

osdba · 2021-05-21 14:47:51发表 · 12586 次点击
   0    0   

1. 前言

中启乘数科技是Greenplum解决方案的领先数据库服务商，专注极致的性能优化，为用户提供高性能、大并发和PB级别的数据仓库解决方案，本测试由中启乘数科技数据库专家完成测试。本次测试的使用了以下两个海量数据的场景：

  • pgbench 造数据 50亿
  • 造sysbench形式的数据近1TB

2. 为什么需要ScaleFlux盘的压缩功能

按ScaleFlux公司对自己的定义：

ScaleFlux是可计算（Computational Storage）技术的行业领先厂商。

这个定义太书面化，我这里简单翻译一下，ScaleFlux主要生产硬件带有透明压缩功能的NVMe盘的厂商，简单说就是提供一块盘，实际容量是3.2T，但是你可以当成9.6T或更大使用。数据存储磁盘时会自动压缩，读取时会自动解压。

我们知道近期硬盘都在涨价，使用压缩功能节省空间，将大大节省我们的成本。

同时我们知道Greenplum数据库本身有压缩功能，为什么还需要在硬件上做压缩呢？最主要的原因是Greenplum的压缩表必须是AO表，AO表有以下限制：

  • AO表对于UPDATE和DELETE操作会在表上加表锁，也就是UPDATE和DELETE不能并发。INSERT和INSERT可以并发，但最多支持127个并发插入。
  • AO表不支持主键和唯一索引。
  • AO表上走索引扫描做等值查询基本只能走Bitmap Index Scan。

而如果我们直接使用ScaleFlux盘的透明压缩功能，就可以使用普通表，就没有了上面的限制。

当然使用ScaleFlux盘的透明压缩功能，对Greenplum集群还带来了以下好处：

  • 减少了CPU的占用。我们知道压缩和解压是非常耗费CPU的操作，把这部分工作移动到硬件上，会大大降低压缩和解压对CPU的消耗。
  • 提高了性能，使用硬件的压缩功能，速度会更快，延迟更低。

3. 安装ScaleFlux盘和驱动

安装

  1. yum localinstall sfx3xdriver-3.2.XXX.rpm

安装驱动完成后，硬盘就出来了：

  1. [root@csyun01 ~]# lsblk
  2. NAME                  MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
  3. sdb                     8:16    0  200G  0 disk
  4. ├─vgsata01-lv00000002 251:1     0 19.5G  0 lvm
  5. └─vgsata01-lv00000001 251:0     0 29.3G  0 lvm
  6. sfdv0n1               252:0     0  2.9T  0 disk
  7. sdc                     8:32    0  200G  0 disk
  8. ├─sdc9                  8:41    0    8M  0 part
  9. └─sdc1                  8:33    0  200G  0 part
  10. sda                     8:0     0  200G  0 disk
  11. ├─sda2                  8:2     0   32G  0 part /
  12. ├─sda3                  8:3     0   16G  0 part [SWAP]
  13. └─sda1                  8:1     0  200M  0 part /boot/efi

盘实际大小为3.2T，我们做成9.6T:

  1. sfx-nvme sfx change-cap /dev/sfdv0n1 -c 9600

把盘格式化为xfs，挂载到/data01:

  1. mkfs.xfs -f -i size=512 -l size=128m,lazy-count=1 -d agcount=16 -L data01 /dev/sfdv0n1
  2. mount -o discard /dev/sfdv0n1 /data01

由于只有一台物理机器， 我们安装LXC容器，做三个容器，相当于三台虚拟机，做成1个MASTER节点2个SEGMENT节点的GREENPLUM，具体做法略。

4. 测试过程与结果

4.1 场景一，使用pgbench造50亿数据

  1. time pgbench -i -s 50000
  2. ...
  3. ...
  4. 4999500000 of 5000000000 tuples (99%) done (elapsed 2124.38 s, remaining 0.21 s).
  5. 4999600000 of 5000000000 tuples (99%) done (elapsed 2124.41 s, remaining 0.17 s).
  6. 4999700000 of 5000000000 tuples (99%) done (elapsed 2124.47 s, remaining 0.13 s).
  7. 4999800000 of 5000000000 tuples (99%) done (elapsed 2124.50 s, remaining 0.08 s).
  8. 4999900000 of 5000000000 tuples (99%) done (elapsed 2124.55 s, remaining 0.04 s).
  9. 5000000000 of 5000000000 tuples (100%) done (elapsed 2124.59 s, remaining 0.00 s).
  10. vacuum...
  11. set primary keys...
  12. done.
  14. real    103m18.492s
  15. user    21m47.415s
  16. sys     0m33.083s

从上面可以看出插入50亿条数据，时间是2125秒，即不到一个小时，加上后面的vacuum和建主键花了较长的时间，总共是103分18秒。

我们看看压缩率情况：

  1. [root@csyun01 data01]# cat /sys/block/sfdv0n1/sfx_smart_features/sfx_logical_size
  2. 1545834440
  3. [root@csyun01 data01]# cat /sys/block/sfdv0n1/sfx_smart_features/sfx_physical_size
  4. 234608808

上面的结果中的单位是扇区数，压缩后占用空间为: 234608808/2048=114555MB，压缩前的空间：1545834440/2048=754801MB，压缩比为 6.6:1。压缩率很高的原因是pgbench造出了很多的重复的数据。

顺带pgbench跑一下在50亿数据下的TPC-B的结果值，基本可以跑到8000，还是挺不错的：

  1. [gpadmin@gp01 ~]$ pgbench -P 2 -c 8  -T 1000
  2. starting vacuum...end.
  3. progress: 2.0 s, 2925.4 tps, lat 2.702 ms stddev 2.840
  4. progress: 4.0 s, 3177.5 tps, lat 2.516 ms stddev 0.175
  5. progress: 6.0 s, 3188.5 tps, lat 2.509 ms stddev 0.178
  6. progress: 8.0 s, 3183.5 tps, lat 2.512 ms stddev 0.180
  7. progress: 10.0 s, 3204.4 tps, lat 2.496 ms stddev 0.180
  8. ^C
  9. [gpadmin@gp01 ~]$ pgbench -P 2 -c 4  -T 1000
  10. starting vacuum...end.
  11. progress: 2.0 s, 1769.5 tps, lat 2.246 ms stddev 2.702
  12. progress: 4.0 s, 1897.0 tps, lat 2.107 ms stddev 0.173
  13. progress: 6.0 s, 1888.9 tps, lat 2.117 ms stddev 0.179
  14. ^C
  15. [gpadmin@gp01 ~]$ pgbench -P 2 -c 16 -T 1000
  16. starting vacuum...end.
  17. progress: 2.0 s, 4589.0 tps, lat 3.411 ms stddev 3.169
  18. progress: 4.0 s, 4942.5 tps, lat 3.236 ms stddev 0.331
  19. progress: 6.0 s, 4913.0 tps, lat 3.256 ms stddev 0.346
  20. progress: 8.0 s, 4894.5 tps, lat 3.268 ms stddev 0.334
  21. progress: 10.0 s, 4813.9 tps, lat 3.323 ms stddev 0.343
  22. progress: 12.0 s, 4917.6 tps, lat 3.253 ms stddev 0.314
  23. progress: 14.0 s, 4992.0 tps, lat 3.204 ms stddev 0.397
  24. ^C
  25. [gpadmin@gp01 ~]$ pgbench -P 2 -c 32 -T 1000
  26. starting vacuum...end.
  27. progress: 2.0 s, 7462.5 tps, lat 4.111 ms stddev 3.018
  28. progress: 4.0 s, 8014.9 tps, lat 3.991 ms stddev 0.731
  29. progress: 6.0 s, 7205.8 tps, lat 4.440 ms stddev 0.998
  30. progress: 8.0 s, 8191.8 tps, lat 3.906 ms stddev 0.741
  31. progress: 10.0 s, 8207.9 tps, lat 3.899 ms stddev 0.647
  32. progress: 12.0 s, 8056.0 tps, lat 3.971 ms stddev 0.666
  33. progress: 14.0 s, 8262.9 tps, lat 3.873 ms stddev 0.612
  34. progress: 16.0 s, 8247.1 tps, lat 3.879 ms stddev 0.730
  35. progress: 18.0 s, 7094.0 tps, lat 4.509 ms stddev 1.091
  36. progress: 20.0 s, 7971.3 tps, lat 4.014 ms stddev 0.679
  37. progress: 22.0 s, 7936.6 tps, lat 4.032 ms stddev 3.529
  38. progress: 24.0 s, 8166.1 tps, lat 3.919 ms stddev 0.658
  39. progress: 26.0 s, 8189.0 tps, lat 3.907 ms stddev 0.631
  40. progress: 28.0 s, 8083.3 tps, lat 3.958 ms stddev 0.682
  41. progress: 30.0 s, 7251.7 tps, lat 4.411 ms stddev 1.051
  42. progress: 32.0 s, 8005.4 tps, lat 3.999 ms stddev 0.718
  43. progress: 34.0 s, 8163.5 tps, lat 3.918 ms stddev 0.659
  44. progress: 36.0 s, 8150.6 tps, lat 3.926 ms stddev 0.651
  45. progress: 38.0 s, 8243.0 tps, lat 3.882 ms stddev 0.746
  46. progress: 40.0 s, 8198.4 tps, lat 3.902 ms stddev 0.640
  47. ^C

　4.2 场景二：造sysbench的数据

用文章 http://blog.osdba.net/538.html 中的gendata工具快速生成数据。

开5个窗口，分别造10亿条数据：

  1. ./gendata 1000000000 > 1.dat
  1. ./gendata 1000000000 > 2.dat
  1. ./gendata 1000000000 > 3.dat
  1. ./gendata 1000000000 > 4.dat
  1. ./gendata 1000000000 > 5.dat

造出来的文件基本每个近200GB:

  1. [gpadmin@gp01 sysbench_bin]$ ls -l
  2. total 975487196
  3. -rw-rw-r-- 1 gpadmin gpadmin 199777792110 May 18 15:59 1.dat
  4. -rw-rw-r-- 1 gpadmin gpadmin 199777775870 May 18 16:02 2.dat
  5. -rw-rw-r-- 1 gpadmin gpadmin 199777768927 May 18 16:08 3.dat
  6. -rw-r--r-- 1 gpadmin gpadmin 199777776805 May 18 16:09 4.dat
  7. -rw-r--r-- 1 gpadmin gpadmin 199777785304 May 18 16:09 5.dat
  8. -rw-r--r-- 1 gpadmin gpadmin        35147 May 18 14:18 LICENSE
  9. -rw-r--r-- 1 gpadmin gpadmin         3759 May 18 14:18 README.md
  10. -rwx------ 1 gpadmin gpadmin          371 May 18 14:18 bench.sh
  11. -rwxrwxr-x 1 gpadmin gpadmin         8696 May 18 15:32 gendata
  12. -rw-rw-r-- 1 gpadmin gpadmin         2023 May 18 15:29 gendata.c
  13. -rwx------ 1 gpadmin gpadmin          370 May 18 17:52 gpbench.sh
  14. drwxr-xr-x 2 gpadmin gpadmin           34 May 18 14:18 img
  15. drwxr-xr-x 2 gpadmin gpadmin         4096 May 18 14:18 lua
  16. -rwxr-xr-x 1 gpadmin gpadmin      3307216 May 18 14:18 sysbench_mysql
  17. -rwxr-xr-x 1 gpadmin gpadmin      3324397 May 18 14:18 sysbench_ora
  18. -rwxr-xr-x 1 gpadmin gpadmin      3253979 May 18 14:18 sysbench_pg

开5个窗口同往GP里灌数据： 

  1. postgres=# copy sbtest1 from '/home/gpadmin/sysbench_bin/1.dat' (format csv);
  2. COPY 1000000000
  3. Time: 24585621.459 ms
  1. postgres=# copy sbtest2 from '/home/gpadmin/sysbench_bin/2.dat' (format csv);
  2. COPY 1000000000
  3. Time: 24877864.760 ms
  1. postgres=# copy sbtest3 from '/home/gpadmin/sysbench_bin/3.dat' (format csv);
  2. COPY 1000000000
  3. Time: 24796154.435 ms
  1. postgres=# copy sbtest4 from '/home/gpadmin/sysbench_bin/4.dat' (format csv);
  2. COPY 1000000000
  3. Time: 24911173.567 ms
  1. postgres=# copy sbtest5 from '/home/gpadmin/sysbench_bin/5.dat' (format csv);
  2. COPY 1000000000
  3. Time: 24524541.338 ms

灌数据基本花了近7个小时，慢的原因是sbtest1~sbtest5上有索引导致的慢：

  1. postgres=# \d sbtest1
  2.                              Table "public.sbtest1"
  3.  Column |      Type      |                      Modifiers
  4. --------+----------------+------------------------------------------------------
  5.  id     | integer        | not null default nextval('sbtest1_id_seq'::regclass)
  6.  k      | integer        | not null default 0
  7.  c      | character(120) | not null default ''::bpchar
  8.  pad    | character(60)  | not null default ''::bpchar
  9. Indexes:
  10.     "sbtest1_pkey" PRIMARY KEY, btree (id)
  11.     "k_1" btree (k)
  12. Distributed by: (id)

为了验证是否是因为索引导致导入数据变慢，我们把表上的索引删除掉，然后再测试，发现导入不到一个1小时就可以导入：

  1. postgres=# copy sbtest1 from '/home/gpadmin/sysbench_bin/1.dat' (format csv);
  2. COPY 1000000000
  3. Time: 2355138.816 ms

上面的5个COPY同时灌数据是，IO的吞吐量基本在2~3 GB/S，ScaleFlux的IO能力还是很强的。

  1. [root@csyun01 sysbench_bin]# iostat -dmx 2 sfdv0n1
  2. Linux 4.14.35-1902.300.11.el7uek.x86_64 (csyun01)     05/18/2021     _x86_64_    (40 CPU)
  4. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  5. sfdv0n1           0.00     0.31  374.54 1911.78    56.71   564.51   556.47     1.86    0.82    0.69    0.84   0.06  13.31
  7. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  8. sfdv0n1           0.00    13.50  208.00 43936.00    52.00  3058.04   144.29    28.23    0.64    1.69    0.64   0.02  99.75
  10. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  11. sfdv0n1           0.00     2.00  176.50 33779.50    43.99  2796.57   171.32    24.43    0.73    1.55    0.72   0.03  99.70
  13. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  14. sfdv0n1           0.00     0.00  160.00 40108.50    40.00  2558.44   132.15    29.53    0.74    1.69    0.73   0.02  99.85
  16. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  17. sfdv0n1           0.00    12.50  181.50 38898.50    45.38  3059.80   162.73    28.27    0.73    2.13    0.72   0.03  99.85

表的大小：

  1. postgres=# select pg_total_relation_size('sbtest1');
  2.  pg_total_relation_size
  3. ------------------------
  4.            334309294080
  5. (1 row)
  7. postgres=# select pg_relation_size('sbtest1');
  8.  pg_relation_size
  9. ------------------
  10.      282482769920
  11. (1 row)
  13. postgres=# select count(*) from sbtest1;
  14.    count
  15. ------------
  16.  1000000000
  17. (1 row)
  19. Time: 136522.604 ms

我们看看压缩率情况：

  1. [root@csyun01 ~]# cat /sys/block/sfdv0n1/sfx_smart_features/sfx_physical_size
  2. 2564817056
  3. [root@csyun01 ~]# cat /sys/block/sfdv0n1/sfx_smart_features/sfx_logical_size
  4. 5821770024

上面的结果中的单位是扇区数，压缩后占用空间为: 2564817056/2048/1024=1223GB，压缩前的空间：1545834440/2048=2776GB，压缩比为 2.27:1。压缩率比之前低的原因是sysbench的数据都是通过随机数填充的。

5. 结论

用pgbench造出的大量重复数据，ScaleFlux压缩率可以达到6.6:1，而使用sysbench的随机数生成的数据，压缩率可以达到2.27:1。

在大批量加载数据过程中，ScaleFlux写吞吐量可以达到2~3GB/s。

从上面的数据看，在Greenplum中使用ScaleFlux卡可以收获很好的效果。

本站文章，未经作者同意，请勿转载，如需转载，请邮件customer@csudata.com.
0 评论  
添加一条新评论

用户登录

个人首页
立即登录