小编最近在做一个超大表的性能测试，在过程中发现无序uuid做主键对表插入性能有些影响，纠结该怎么处理这一问题呢？接下来小编给大家分享postgresql无序uuid性能测试的相关知识帮助大家学习，需要的彭参考下吧
无序uuid对数据库的影响
由于最近在做超大表的性能测试，在该过程中发现了无序uuid做主键对表插入性能有一定影响。结合实际情况发现当表的数据量越大，对表插入性能的影响也就越大。
测试环境
PostgreSQL创建插入脚本，测试各种情况的tps。
数据库版本：PostgreSQL 10.4 (ArteryBase 5.0.0, Thunisoft)
操作系统配置：CentOS Linux release 7 ，32GB内存，8 cpu
测试参数：pgbench -M prepared -r -n -j 8 -c 8 -T 60 -f /opt/thunisoft/pgbench_uuid_v4.sql -U sa pgbenchdb
空表，1000w数据，5000w数据，一亿数据的各种主键测试。
测试无序的uuid，有序的uuid，序列，有普通btree，有唯一索引和没有主键的情况
测试
1.创建表
--无序的uuid pgbenchdb=# create table test_uuid_v4(id char(32) primary key); CREATE TABLE --有序的uuid pgbenchdb=# create table test_time_nextval(id char(32) primary key); CREATE TABLE --递增序列 pgbenchdb=# create table test_seq_bigint(id int8 primary key); CREATE TABLE --创建序列 create sequence test_seq start with 1 ;
2.测试脚本
--测试无序uuid脚本 vi pgbench_uuid_v4.sql insert into test_uuid_v4 (id) values (replace(uuid_generate_v4()::text,'-','')); --测试有序uuid脚本 vi pgbench_time_nextval.sql insert into test_time_nextval (id) values (replace(uuid_time_nextval()::text,'-','')); --测试序列脚本 vi pgbench_seq_bigint.sql insert into test_seq_bigint (id) values (nextval('test_seq'::regclass));无序uuid,无数据情况
磁盘使用情况 avg-cpu: %user %nice %system %iowait %steal %idle 0.76 0.00 0.38 4.67 0.00 94.19 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 0.00 0.00 96.00 0.00 2048.00 42.67 1.02 10.67 0.00 10.67 10.33 99.20 dm-0 0.00 0.00 0.00 96.00 0.00 2048.00 42.67 1.02 10.66 0.00 10.66 10.32 99.10 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 tps： [thunisoft@localhost thunisoft]$ pgbench -M prepared -r -n -j 8 -c 8 -T 60 -f /opt/thunisoft/pgbench_uuid_v4.sql -U sa pgbenchdb transaction type: /opt/thunisoft/pgbench_uuid_v4.sql scaling factor: 1 query mode: prepared number of clients: 8 number of threads: 8 duration: 60 s number of transactions actually processed: 53494 latency average = 8.974 ms tps = 891.495404 (including connections establishing) tps = 891.588967 (excluding connections establishing) script statistics: - statement latencies in milliseconds: 9.006 insert into test_uuid_v4 (id) values (replace(uuid_generate_v4()::text,'-',''));
无数据情况下，tps
类别 | 第一次 | 第二次 | 第三次 | 平均值(tps) |%util |await ---------------+---------+---------+---------+---------+-------+------- 无序uuid | 919 | 907 | 891 | 906 | 99.2% | 10.66 有序uuid | 985 | 882 | 932 | 933 | 98.7% | 4.4 序列 | 1311 | 1277 | 1280 | 1289 | 97.5% | 3.4
向表里面初始化100w数据
pgbenchdb=# insert into test_uuid_v4 (id) select replace(uuid_generate_v4()::text,'-','') from generate_series(1,1000000); INSERT 0 1000000 Time: 43389.817 ms (00:43.390) pgbenchdb=# insert into test_time_nextval (id) select replace(uuid_time_nextval()::text,'-','') from generate_series(1,1000000); INSERT 0 1000000 Time: 30585.134 ms (00:30.585) pgbenchdb=# insert into test_seq_bigint select generate_series (1,1000000); INSERT 0 1000000 Time: 9818.639 ms (00:09.819) 无序uuid插入100w需要43s，有序需要30s，序列需要10s。
插入一百万数据后的tps
类别 | 第一次 | 第二次 | 第三次 | 平均值(tps) |%util |await ---------------+---------+---------+---------+---------+-------+------- 无序uuid | 355 | 440 | 302 | 365 | 98.8% | 13 有序uuid | 948 | 964 | 870 | 927 | 97.2% | 4.0 序列 | 1159 | 1234 | 1115 | 1169 | 96.6% | 3.5
插入一千万数据后的tps
类别 | 第一次 | 第二次 | 第三次 | 平均值(tps) |%util |await ---------------+---------+---------+---------+---------+-------+------- 无序uuid | 260 | 292 | 227 | 260 | 99.2% | 16.8 有序uuid | 817 | 960 | 883 | 870 | 97.7% | 3.9 序列 | 1305 | 1261 | 1270 | 1278 | 96.8% | 3.0
插入五千万数据后
向表中插入5kw数据，并且添加主键 pgbenchdb=# insert into test_time_nextval (id) select replace(uuid_time_nextval()::text,'-','') from generate_series(1,50000000); INSERT 0 50000000 Time: 453985.318 ms (07:33.985) pgbenchdb=# insert into test_seq_bigint select generate_series (1,50000000); INSERT 0 50000000 Time: 352206.160 ms (05:52.206) pgbenchdb=# inse以上就是postgresql无序uuid性能测试及对数据库的影响的详细内容，更多请关注0133技术站其它相关文章！
