如何体现timescaledb在insert过程中比原生PG的优势？

最新推荐文章于 2023-11-28 20:49:45 发布

小湿哥

最新推荐文章于 2023-11-28 20:49:45 发布

阅读量577

点赞数 1

分类专栏： PG学习笔记

本文链接：https://blog.csdn.net/jacicson1987/article/details/83416015

版权

PG学习笔记专栏收录该内容

13 篇文章 0 订阅

订阅专栏

CASE-1 减少shared_buffer 从3GB到512MB。

CASE-2， 4个索引，4并发，总共4亿行数据，监控PG实时写入速率

CASE-3 改用HDD机械硬盘测试

接上周一篇 timescaledb和PG写入性能测试 https://blog.csdn.net/jacicson1987/article/details/83064313

经过1亿数据量的测试，并没有发现timescaledb的在insert方面的优势。timescaledb官网上也只有一张图，并没有详细的测试场景介绍。

官网的说明是，数据量足够大，当PG的索引不在适合内存的时候，每次插入要更加频繁的访问磁盘获取索引，导致性能急剧下降。

尝试复现PG性能随着数据量/索引增大，性能下降的曲线。

测试环境与之前保持一致。

CASE-1 减少shared_buffer 从3GB到512MB。

1亿行数据，单线程，2个索引

总速率（行/s）	单线程
timescaledb	24066
PG	25046

减少shared_buffer没有效果，还是PG快。

CASE-2， 4个索引，4并发，总共4亿行数据，监控PG实时写入速率

PG单测	总行数	time cost	速率（行/s）
线程1	100000000	6320	15823
线程2	100000000	6300	15873
线程3	100000000	6333	15790
线程4	100000000	6342	15768
Total	400000000	6342	63072

实时监控其速度，保持稳定，从开始到结束，一致稳定在6.3W行/s 小幅波动。

表大小 86GB，索引 47GB

postgres=# select pg_size_pretty(pg_relation_size('cts1_time_idx'));
 pg_size_pretty 
----------------
 14 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_id_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_col2_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_col3_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)
postgres=# select pg_size_pretty(pg_table_size('cts1'));
 pg_size_pretty 
----------------
 86 GB
(1 row)

早就超过内存最大值32GB。PG性能无衰减。

怀疑SSD性能太好，访问索引开销不足以使得性能下降，观察disk使用率都没超过70%。