2.测试脚本
无序uuid,无数据情况
无数据情况下，tps
向表里面初始化100w数据
插入一百万数据后的tps
插入一千万数据后的tps
插入五千万数据后
插入5kw后
插入1亿条数据后
普通btree索引上面测了无序uuid，1kw情况下，有主键的tps是260，无主键的tps是1234。尝试测试普通的索引，和唯一索引tps
无论是普通btree索引和唯一索引，都会影响插入的效率。
删除所有的主键索引删除主键约束后，三种情况下tps非常接近，都达到了1200+。
Btree索引，插入操作的平均tps对比
根据测试数据可以看出无序的uuid在数据到达1kw后插入数据的tps下降的非常厉害，而有序的uuid和递增序列下降的比较少。到一亿数据的tps有序uuid是无序的6倍，序列是无序uuid的9倍。
创建单独的表空间用来存储索引信息如果有多快磁盘那么可以将索引和数据分开存储，以此来加快写入的速度。
创建单独的索引空间：
create tablespace indx_test owner sa location '/home/tablespace/index_test';
指定索引存储目录：
create index i_test_uuid_v4_id on test_uuid_v4 using btree(id) tablespace indx_test;
关于有序uuid测试使用的sequential-uuids插件，生成的有序uuid。
有序uuid的结构为(block ID; random data)，实际上就是把数据拆成两部分，一部分自增，一部分随机。
sequential-uuids
sequential-uuids-git
提供了两种算法：
1.uuid_sequence_nextval(sequence regclass, block_size int default 65536, block_count int default 65536)
前缀为自增序列，如果块ID使用2字节存储，一个索引BLOCK里面可以存储256条记录（假设8K的BLOCK，一条记录包括uuid VALUE（16字节）以及ctid（6字节），所以一个索引页约存储363条记录（8000 /（16 + 6）））
2.uuid_time_nextval(interval_length int default 60, interval_count int default 65536) RETURNS uuid
默认每60秒内的数据的前缀是一样的，前缀递增1，到65535后循环。
有序uuid前四位有序，后面的随机生成。
结语1.关于有序的uuid，前4位是有序的，后面都是随机生成的。
2.在该环境中发现，无序uuid随着数据量的不断增大，tps下滑比较厉害。
3.由于btree索引的存在，无序的uuid会导致大量的离散io。导致磁盘使用率高。进而影响插入效率。随着表数据量的增大更加明显。
4.该测试是在普通的磁盘上面测试，并未在ssd上面测试。
5.如果要使用有序uuid，有多种实现方式，还需要考虑分布式情况下生成全局有序uuid。
以上就是postgresql无序uuid性能测试的详细内容，更多关于postgresql无序uuid性能测试的资料请关注七叶笔记其它相关文章！
