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

我不是女神ヾ 2023-10-01 22:33 11阅读 0赞

#### 目录 ####

*   *  背景
     *  测试方案
     *   *  部署环境：
         *  Sysbench压测选择7个常用场景：
     *  测试结果
     *   *  1、select\\\_random\\\_points
         *  2、oltp\\\_read\\\_only
         *  3、oltp\\\_write\\\_only
         *  4、oltp\\\_read\\\_write
         *  5、oltp\\\_update\\\_index
         *  6、oltp\\\_update\\\_non\\\_index
         *  7、oltp\\\_delete
     *  总结

--------------------

### 背景 ###

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

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

![d20078ae2bf5268d51114c555fe4858b.jpeg][]

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

*  [TiDB for PostgreSQL—牛刀小试][TiDB for PostgreSQL]
 *  [TiDB for PostgreSQL 学习指南][TiDB for PostgreSQL 1]
 *  [TiDB for PostgreSQL之兼容GitLab][TiDB for PostgreSQL_GitLab]

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

--------------------

### 测试方案 ###

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

#### 部署环境： ####

<table> 
 <thead> 
  <tr> 
   <th>机器名称</th> 
   <th>参数值</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>数据库节点-1</td> 
   <td>物理机，NUC 10 x86，12c 64G 1Tssd</td> 
   <td>yugabytedb：1个master、1个 tserver tidb4pg：1个pd、1个tidb、1个tikv</td> 
  </tr> 
  <tr> 
   <td>数据库节点-2</td> 
   <td>物理机，NUC 10 x86，12c 64G 1Tssd</td> 
   <td>同上</td> 
  </tr> 
  <tr> 
   <td>数据库节点-3</td> 
   <td>物理机，NUC 10 x86，12c 64G 1Tssd</td> 
   <td>同上</td> 
  </tr> 
  <tr> 
   <td>Sysbench压测机</td> 
   <td>虚拟机，x86，16c 32G</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>Haproxy负载均衡</td> 
   <td>虚拟机，x86，8c 16G</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

#### 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%延时指标做两种数据库对比。

--------------------

### 测试结果 ###

#### 1、select\_random\_points ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>4044</td> 
   <td>3.49</td> 
   <td>2666</td> 
   <td>5.47</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>8398</td> 
   <td>10.09</td> 
   <td>5086</td> 
   <td>15.00</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>8754</td> 
   <td>20</td> 
   <td>5429</td> 
   <td>29.19</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>9441</td> 
   <td>36.89</td> 
   <td>5541</td> 
   <td>58.92</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>9785</td> 
   <td>52.89</td> 
   <td>5531</td> 
   <td>92.42</td> 
  </tr> 
 </tbody> 
</table>

![f0c8c24105f96d2c0e85ba76948b924e.png][]

**结果分析**：

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

#### 2、oltp\_read\_only ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>8954</td> 
   <td>20.74</td> 
   <td>0.13</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>24262</td> 
   <td>38.94</td> 
   <td>0.15</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>25136</td> 
   <td>78.60</td> 
   <td>0.15</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>25267</td> 
   <td>158.63</td> 
   <td>0.14</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>25436</td> 
   <td>240.02</td> 
   <td>0.14</td> 
   <td>-</td> 
  </tr> 
 </tbody> 
</table>

**结果分析**：

这个场景测试结果差异非常大，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的范围查询效率这么低还要进一步分析。

#### 3、oltp\_write\_only ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>790</td> 
   <td>90.78</td> 
   <td>4309</td> 
   <td>47.47</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>3540</td> 
   <td>104.84</td> 
   <td>8427</td> 
   <td>71.83</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>6486</td> 
   <td>114.72</td> 
   <td>8674</td> 
   <td>92.42</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>11414</td> 
   <td>132.49</td> 
   <td>11170</td> 
   <td>150.29</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>15133</td> 
   <td>155.80</td> 
   <td>12036</td> 
   <td>211.60</td> 
  </tr> 
 </tbody> 
</table>

![21b8d31e97a0c84c977f132c0d5cfb82.png][]

**结果分析**：

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

#### 4、oltp\_read\_write ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>2238</td> 
   <td>104.84</td> 
   <td>556</td> 
   <td>3151.62</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>9790</td> 
   <td>123.28</td> 
   <td>1485</td> 
   <td>3326</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>17454</td> 
   <td>137.35</td> 
   <td>1494</td> 
   <td>6960</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>25119</td> 
   <td>189.93</td> 
   <td>1402</td> 
   <td>14302</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>25967</td> 
   <td>272.27</td> 
   <td>1835</td> 
   <td>22034</td> 
  </tr> 
 </tbody> 
</table>

**结果分析**：

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

#### 5、oltp\_update\_index ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>374</td> 
   <td>36.24</td> 
   <td>2227</td> 
   <td>11.65</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>1630</td> 
   <td>41.85</td> 
   <td>3754</td> 
   <td>21.89</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>2980</td> 
   <td>45.79</td> 
   <td>4266</td> 
   <td>36.24</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>5375</td> 
   <td>50.11</td> 
   <td>4845</td> 
   <td>62.19</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>7298</td> 
   <td>55.82</td> 
   <td>4964</td> 
   <td>92.42</td> 
  </tr> 
 </tbody> 
</table>

![55064a36684149205d60c410bab142eb.png][]

**结果分析**：

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

#### 6、oltp\_update\_non\_index ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>415</td> 
   <td>31.37</td> 
   <td>6847</td> 
   <td>2.03</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>1988</td> 
   <td>35.59</td> 
   <td>17123</td> 
   <td>4.65</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>3761</td> 
   <td>37.56</td> 
   <td>16246</td> 
   <td>9.91</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>6910</td> 
   <td>41.10</td> 
   <td>18928</td> 
   <td>20.37</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>9849</td> 
   <td>43.39</td> 
   <td>19896</td> 
   <td>29.72</td> 
  </tr> 
 </tbody> 
</table>

![49f14ef078ab26b14d5ebf49f2541963.png][]

**结果分析**：

update\_non\_index是根据主键更新非索引列，在这一场景中YugabyteDB大幅领先TiDB For PostgreSQL并且持续保持。

#### 7、oltp\_delete ####

<table> 
 <thead> 
  <tr> 
   <th>线程数</th> 
   <th>QPS（TiDB4PG）</th> 
   <th>95% Latency（TiDB4PG）</th> 
   <th>QPS（YugabyteDB）</th> 
   <th>95% Latency（YugabyteDB）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>10</td> 
   <td>364</td> 
   <td>37.56</td> 
   <td>2389</td> 
   <td>10.84</td> 
  </tr> 
  <tr> 
   <td>50</td> 
   <td>1568</td> 
   <td>43.39</td> 
   <td>4269</td> 
   <td>19.65</td> 
  </tr> 
  <tr> 
   <td>100</td> 
   <td>2899</td> 
   <td>46.63</td> 
   <td>4844</td> 
   <td>33.12</td> 
  </tr> 
  <tr> 
   <td>200</td> 
   <td>5380</td> 
   <td>50.11</td> 
   <td>5705</td> 
   <td>56.84</td> 
  </tr> 
  <tr> 
   <td>300</td> 
   <td>7622</td> 
   <td>54.83</td> 
   <td>6146</td> 
   <td>82.96</td> 
  </tr> 
 </tbody> 
</table>

![0c8cbf533c721f70a1239a677a318f7a.png][]

**结果分析**：

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

--------------------

### 总结 ###

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

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

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

**版权声明**:本文由神州数码云基地团队整理撰写，若转载请注明出处。  
公众号搜索神州数码云基地，后台回复TiDB，加入TiDB技术交流群。

[Stack Overflow 2022]: https://survey.stackoverflow.co/2022/
[d20078ae2bf5268d51114c555fe4858b.jpeg]: https://img-blog.csdnimg.cn/img_convert/d20078ae2bf5268d51114c555fe4858b.jpeg
[TiDB for PostgreSQL]: https://zhuanlan.zhihu.com/p/379181280
[TiDB for PostgreSQL 1]: https://zhuanlan.zhihu.com/p/383500491
[TiDB for PostgreSQL_GitLab]: https://zhuanlan.zhihu.com/p/448122284
[f0c8c24105f96d2c0e85ba76948b924e.png]: https://img-blog.csdnimg.cn/img_convert/f0c8c24105f96d2c0e85ba76948b924e.png
[21b8d31e97a0c84c977f132c0d5cfb82.png]: https://img-blog.csdnimg.cn/img_convert/21b8d31e97a0c84c977f132c0d5cfb82.png
[55064a36684149205d60c410bab142eb.png]: https://img-blog.csdnimg.cn/img_convert/55064a36684149205d60c410bab142eb.png
[49f14ef078ab26b14d5ebf49f2541963.png]: https://img-blog.csdnimg.cn/img_convert/49f14ef078ab26b14d5ebf49f2541963.png
[0c8cbf533c721f70a1239a677a318f7a.png]: https://img-blog.csdnimg.cn/img_convert/0c8cbf533c721f70a1239a677a318f7a.png