TiDB For PostgreSQL和YugabyteDB在Sysbench上的性能对比

Posted PostgreSQLChina

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TiDB For PostgreSQL和YugabyteDB在Sysbench上的性能对比相关的知识,希望对你有一定的参考价值。

1 背景

PostgreSQL是一款知名的开源数据库产品,作为数字化的基础设施在大型企业级应用中扮演着重要的角色,它的许多高级特性被广泛应用在各种复杂场景中。

根据Stack Overflow 2022 开发者调查报告显示,PostgreSQL已经超越mysql成为开发者最喜爱的数据库软件。

在近些年的数据库领域中分布式数据库是当下的发展趋势,基于PostgreSQL协议的分布式数据库国外诞生了诸如CockroachDB、YugabyteDB这样的优秀产品,而国内的热门分布式数据库TiDB官方只提供了MySQL协议的支持,神州数码技术团队基于开源TiDB研发了TiDB For PostgreSQL版本,目前已经实现了主流应用兼容,参考资料:

  • TiDB for PostgreSQL—牛刀小试  

  • TiDB for PostgreSQL 学习指南  

  • TiDB for PostgreSQL之兼容GitLab

他们同属NewSQL范畴且实现了PG协议,但具体架构实现上还是有差异性,我们非常好奇两者性能对比之下表现如何。

2 测试方案

准备3台物理机用来搭建分布式数据库,分别搭建3节点的YugabyteDB集群和TiDB For PostgreSQL集群,全部使用默认参数部署,数据库之上使用Haproxy做负载均衡代理。这样能尽可能地保证两者的部署架构一致,减少实验误差。

部署环境:

机器名称参数值备注
数据库节点-1物理机,NUC 10 x86,12c 64G 1Tssdyugabytedb:1个master、1个 tserver  tidb4pg:1个pd、1个tidb、1个tikv
数据库节点-2物理机,NUC 10 x86,12c 64G 1Tssd同上
数据库节点-3物理机,NUC 10 x86,12c 64G 1Tssd同上
Sysbench压测机虚拟机,x86,16c 32G
Haproxy负载均衡虚拟机,x86,8c 16G

Sysbench压测选择7个常用场景:

select_random_points(随机点查)

oltp_read_only(只读事务)

oltp_write_only(只写事务)

oltp_read_write(读写混合事务)

oltp_update_index(带索引更新)

oltp_update_non_index(不带索引更新)

oltp_delete(事务删除)

针对以上每个场景,设置5种不同并发级别,分别是10、50、100、200、300个线程数,持续压测5分钟。
收集每次测试数据中的QPS和95%延时指标做两种数据库对比。

3 测试结果

01 select_random_points

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
1040443.4926665.47
50839810.09508615.00
100875420542929.19
200944136.89554158.92
300978552.89553192.42

结果分析:

在点查场景上TIDB For PostgreSQL比YugabyteDB要稍微领先一些,而且随着并发量增大,这个差距被拉的越来越大。

02 oltp_read_only

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
10895420.740.13-
502426238.940.15-
1002513678.600.15-
20025267158.630.14-
30025436240.020.14-

结果分析:

这个场景测试结果差异非常大,YugabyteDB查询性能受到碾压,TiDB For PostgreSQL在正常水平。

通过分析Sysbench源码发现,只读场景主要是包含以下几条查询SQL:

  SELECT c FROM sbtest1 WHERE id BETWEEN 1 AND 1000;
    SELECT sum(k) FROM sbtest1 WHERE id BETWEEN 1 AND 1000;
    SELECT c FROM sbtest1 WHERE id BETWEEN 1 AND 1000 order by c;
    SELECT distinct c FROM sbtest1 WHERE id BETWEEN 1 AND 1000 order by c;

4条根据主键做范围查的SQL执行下来耗时总共在400秒以上,结果非常让人吃惊。以第一条SQL为例分析它的执行计划:

   Seq Scan on sbtest1  (cost=0.00..105.00 rows=1000 width=484) (actual time=9.968..127393.155 rows=1000 loops=1)
      Filter: ((id >= 1) AND (id <= 1000))
      Rows Removed by Filter: 9999000
    Planning Time: 0.048 ms
    Execution Time: 127393.919 ms

按照以往晶经验来说应该直接走主键索引扫描,但实际上是用了全表扫描,令人迷惑。

为了验证是否查询范围大小的影响,我把id的查询范围限制在1到10,发现还是一样的执行计划,如果改用in查询的话就可以走主键索引。

相比而言,TiDB For PostgreSQL的执行计划是在预期内:

    Projection_4    500.09    1000    root    
    └─IndexLookUp_13    500.09    1000    root    
      ├─IndexRangeScan_11(Build)    500.09    1000    cop[tikv]    table:sbtest1, index:PRIMARY(id)
      └─TableRowIDScan_12(Probe)    500.09    1000    cop[tikv]    table:sbtest1

到底是什么原因导致YugabyteDB的范围查询效率这么低还要进一步分析。

03 oltp_write_only

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
1079090.78430947.47
503540104.84842771.83
1006486114.72867492.42
20011414132.4911170150.29
30015133155.8012036211

结果分析:

混合写入场景包含4类,也就是后面提到的索引更新、不带索引更新、删除、插入这4种情况,在并发量较小的时候YugabyteDB性能优势明显,但是从200并发开始TiDB For PostgreSQL性能开始反超,可以反映稳定性稍好一些。

04 oltp_read_write

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
102238104.845563151.62
509790123.2814853326
10017454137.3514946960
20025119189.93140214302
30025967272.271835220

结果分析:
混合读写场景同样受到YugabyteDB范围查询的影响,整体性能比TiDB For PostgreSQL要差很多,在50并发量的时候已经达到瓶颈。

05 oltp_update_index

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
1037436.24222711.65
50163041.85375421.89
100298045.79426636.24
200537550.11484562.19
300729855.82496492.

结果分析:

update_index是根据主键更新索引列,在这一场景中YugabyteDB在小并发量时性能更好,但是随着并发量上升会更快达到性能瓶颈,并且会越来越差,TiDB For PostgreSQL相对稳定。

06 oltp_update_non_index

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
1041531.3768472.03
50198835.59171234.65
100376137.56162469.91
200691041.101892820.37
300984943.391989629.

结果分析:
update_non_index是根据主键更新非索引列,在这一场景中YugabyteDB大幅领先TiDB For PostgreSQL并且持续保持。

 07 oltp_delete

线程数QPS(TiDB4PG)95% Latency(TiDB4PG)QPS(YugabyteDB)95% Latency(YugabyteDB)
1036437.56238910.84
50156843.39426919.65
100289946.63484433.12
200538050.11570556.84
300762254.8361468

结果分析:

delete场景是根据主键删除一行记录,这个测试结果类似非索引更新,刚开始YugabyteDB性能较好,并发量上升以后慢慢落后于TiDB For PostgreSQL。

4 总结

经过以上7个场景的测试发现,两种数据库的性能各有优劣。

TiDB For PostgreSQL更擅长读操作,YugabyteDB更擅长写操作,但是随着数据库负载增加,YugabyteDB对大并发请求的处理能力和稳定性不如TiDB For PostgreSQL好。

这其中的差异我们会在后续对两者从架构和底层原理上做深度对比,看能否找出真实的原因。

以上是关于TiDB For PostgreSQL和YugabyteDB在Sysbench上的性能对比的主要内容,如果未能解决你的问题,请参考以下文章

迁移实战:Discourse 从 PostgreSQL 到 MySQL 到 TiDB丨AskTUG 论坛背后的故事

构建实时数仓 - 当 TiDB 偶遇 Pravega

技术分享 | TiDB 对大事务的简单拆分

TIDB3数据库的发展历史现在未来

TiDB Operator + Amazon Web Service,探索云原生数据库的最佳实践

安装配置PgBouncer for PostgreSQL