MyCat与TinyDBRouter性能PK
MyCat与TinyDBRouter性能PK
悠悠然然 发表于2年前
MyCat与TinyDBRouter性能PK
  • 发表于 2年前
  • 阅读 8252
  • 收藏 116
  • 点赞 11
  • 评论 99

【腾讯云】如何购买服务器最划算?>>>   

现在经常说来水平扩展,这个时候一般都会说到数据库的水平扩展,这个时候一般就会用到数据库的分库分表方案。关于这一块,可能大家也都一些开源或商业的方案进行过一些研究。

今天我就简单的拿一些性能测试数据进行简单的展示,看看TinyDbRouter和Mycat与纯纯的JDBC之间的性能差异情况。

环境说明

为了进行这项测试,我就得准备一下测试环境,因为做的是对比测试,因此用多少NB的服务器不是重点。另外,由于虚拟机之间会有CPU、磁盘IO的资源竞争,因此我选择了用独立的计算机进行这项测试,这样才可以真正的模拟水平扩展时的硬件拓展方式。

为此我找了4台笔记本电脑,配置如下:

客户端和服务器 硬件配置:
  硬件平台:windows7旗舰版 32位)物理机
  CPU 4CPUs
  处理器:Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
  内存:4GB
  硬盘:500G
嗯嗯,配置一般,不过做这项测试应该是OK的。

测试方案

这次主要测试多种方式下数据库的插入和查询方面方面的性能差异。

  1. 使用一个数据库,中间加一道分库分表中件间,然后测试直接使用JDBC和加一层中间件之间的性能对比,看看加了一层对性能的影响
  2. 使用两个物理数据库,对数据进行水平分片,然后测试直接使用JDBC操作一个库和用了中间件分成两个库之间的性能做对比

环境说明:为了更好的进行观察和分析,采用MyCat方式式,MyCat采用了独立部署为一台服务器的方式

测试数据

单个数据库增加TinyDBRouter访问时的插入性能影响

从上面的数据可以看到:在没有压力的情况下,在插入时增加了TinyDbRouter与不增加TinyDbRouter层时的性能对比为下降了6.6%,而在有压力的情况下性能下降大致为15%左右。

而在查询的时候,由于查询的时间较插入时间长许多,因此可以看到TinyDbRouter对于查询的影响可以忽略不计。

相同数据量采用TinyDbRouter分库的查询性能对比


从上面的数据可以看到,在没有压力的情况下,插入的速度较单库相比有些许下降,但是随着压力的增加,分片了的性能逐步上升,虽然压力没有加大到最大,但是处理性能已经是未分片的1.5倍左右,说明通过分片确实可以有效提升插入的TPS数量。


我们再来看看查询方面的性能差异,由于同样的记录数,分片方案中把数据均衡的分配到了两个不同的库中,因此不带分库键查询时,查询性能大致是未分库方式的2倍左右浮动(这里的查询条件是动态生成,因此刨除了缓冲方面的因素);带有分库键进行查询时,查询性能大致是未分库方式的4倍左右浮动。

总结,通过分片的方式进行水平扩展,确实可以有效的提升插入和查询的效率。提升效率的多少与水平扩展的数量大致成正比。(实际上,随着分片个数的增加,每台机器的能力扩展系数是在慢慢减小的)。

相同数据量采用MyCat分库的插入性能对比

通过上面的测试,可以看到,使用 MyCat把数据分到两个物理数据库,也有效的提升了插入效率,这方面和TinyDbRouter的基本相同。

相同数据量采用MyCat分库的查询性能对比


接下来就是对MyCat的查询方面的性能进行对比测试,性能数据较不分库有一定提升,但是相对于TinyDbRouter就有一定的差距。

总结

不论是哪种分库分表方案,都可以有效提升插入和查询的TPS。

有分库键查询和没有分库键查询,性能相差明显。

TinyDbRouter和MyCat的数据库水平扩展中间件在插入方面的性能损耗相差不大,在查询方面TinyDbRouter的性能较MyCat有一定的优势,随着集群大小的变化,会导致性能的差距进一步扩大

原因分析如下:

表明原因分析:MyCat服务器自已的CPU占有率比较高,说明其计算量也非常大,导致在MyCat服务器中产生了一定性能损耗。由于MyCat在这种测试方式下是单点,因此随着水平扩展的数据库数量的增加,其单点压力也会越来越大。

深层次原因分析:MyCat是由独立的服务器来进行查询及结果的合并及相关处理,因此必须把数据从数据库服务器取到MyCat服务器上进行一定的运算后再向客户端进行返回数据;而TinyDBRouter由于部署到数据库客户端,因此这部分计算由数据库客户端进行计算,充分的利用了数据库客户端的计算能力,因此不存在单点问题。

同样的一个处理,MyCat的方式是:客户端->MyCat->Mycat计算后->水平扩展的数据服务器(这里是2)->MyCat合并结果后->客户端

而TinyDBRouter的方式是:客户端->(DBRouter计算后)->水平扩展的数据服务器(这里是2)->(DBRouter计算后)->客户端,网络传输次数较MyCat少了一半。另外由于TinyDBRouter的合并计算在客户端进行,因此可以进行更深入的优化以提升数据获取速度。

声明

我们一开始把MyCat服务器和其中一台数据库服务器部署在一台物理机,结果数据非常不合常理,因此才把它独立部署为一台服务器。

我们一开始是用Delete语句清空数据的,后来发现这种方式对测试数据有比较大的影响,同样的数据量与测试方法,数据相去甚远。采用了DROP表现重建的方式后保证了数据的可验证性,同样的数据量与测试方式,数据非常接近。

我们在测试过程中,秉持了客观公正的心态来进行这项测试,也是为了找准自己的位置,和同类产品学习的态度进行的。

我们保证没有对测试数据进行任何的人为调整,而完全忠实于实验中采集的数据。

即使同样时刻的测试数据,也会有轻微的不同,但是差距非常小。


共有 人打赏支持
悠悠然然
粉丝 2321
博文 173
码字总数 360373
作品 14
评论 (99)
红薯
高产!
悠悠然然

引用来自“红薯”的评论

高产!
呵呵,最近一段时间推荐我包了:)
愚民日记
那事物是如何管理,每个 node 都会开事物么?
悠悠然然

引用来自“愚民日记”的评论

那事物是如何管理,每个 node 都会开事物么?

必须支持事务。
空虚的人
找了一下,没有下载地址啊,只看到一个jdbc3的还是2014年的文档,...现在没有几个jdbc3了吧
anduo
mycat 我们会努力的
要命科技技术有限公司
有时间来学习一下
__loong
有营养啊。多谢分享
CalssNotFound
用了一段时间的mycat, 感觉性能上还不错的, TinyDBRouter没用过,不好评论。
mousedogtiger
您好,能否分享下客户端测试代码和测试表结构?
悠悠然然

引用来自“mousedogtiger”的评论

您好,能否分享下客户端测试代码和测试表结构?
因为上述两种方案都是透明的分库分表方案,因此客户端的测试代码就是直接访问JDBC的方式就可以了。
SimonYe
79
songwie
测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉
悠悠然然

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉
亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨
悠悠然然

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉
用我以前博客中的一句话送给你: 牛人在挑战别人之前先研究别人;生手在研究别人之前就挑战别人。 我发这篇文章,准备了4台物理机,搭建了环境,进行了2周左右的测试,收集了大量的数据(为了得出准确的数据排除干扰,大多数数据还进行了几种不同的测试以确定数据的有效性),然后才以数据为基础写了这篇文章。而你大概只花了几秒的时间在大脑里做了一下判断,然后就得出了结论。 所以....
Carvendy
分库分表,这个能推荐点资料么?
悠悠然然

引用来自“Carvendy”的评论

分库分表,这个能推荐点资料么?
本人博客里面相关说明文章。
闲大赋
开源大鳄
乌龟壳

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨
中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。
悠悠然然

引用来自“闲大赋”的评论

开源大鳄

好久不见
×
悠悠然然
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: