0
点赞
收藏
分享

微信扫一扫

为什么我总和性能指标相差很远?

Go_Viola 2022-06-28 阅读 105

我经常看到类似这样的标题某某DB比原生MySQL快N倍。原生的快多少倍其实我觉得不是太重要,甚至是不是比原生的MySQL PG快这也不好说。我们退一万步认为这个假设成立,实际也用不出这个效果。我今天来讲讲为什么。首先一个正常的主流的关系型数据库发挥出每秒几万次,乃至十几万次的读,和几千次写一点问题都没有。这还是在单机的情况下,所以我也一再强调如果业务没有达到单机的瓶颈,就单机(可以主从保障高可用)就好了。不要分库分表,当然单机了甚至单机上的各个schema相互访问一下就好了,不用接口,不用MQ了。一致性都有保障,开发工作量减少非常多。但是为什么我们经常会遇到瓶颈?这里分析一下官方的数据怎么来的?现实的数据怎么来的?

    官方数据库(也称实验室数据),是在理想环境下,按照标准的设计和标准的规范压测的。我猜TPCC也是这样吧?我没参与过,只能猜。实际数据可能过于完美,但是我们可能没有理想的实验室,但是如果也按照标准的设计和标准的规范来做,我觉得打个8-9折还是可以的。

   但是真实情况呢?又是不忍直视啊。似乎MySQL、PG甚至Oracle的原厂都太过理想化我们的实际开发水平了。比如Oracle觉得我们不应该有直接路径读,MySQL以前觉得我们单表或者两表关联,取几条数据,嵌套循环最好为什么要hash join?但是实际上我国现状可能除了大厂的那些开发做得好些,一般的企业很多开发都是全表查询。索引?索引是什么?不清楚。咦,我怎么越查越慢?放缓存吧。分库吧。分表吧。 数据同步吧。消息队列吧。可能官方卖家秀是数据是每秒10万次,而买家秀是100秒1次。这就差了1000万倍的性能。所以官方想的很好,宣传的可能有点夸大,但是实际用下来非常拉胯。

  但是这个锅谁背。我以前一直举例,考驾照时候手动挡的。坡道起步,五档起步。熄火了是怪车还是怪坡?

  通常来说一个并发场景。比如60秒有600个请求,那么最差的要求,每次请求不得超过0.1秒为好。因为一个数据库不太可能就处理一个场景。如果频次X单次时间等于并发区间的话,那么说明CPU基本很忙了。

  所以我们各种性能基本还是依靠SQL质量。那各种数据库能不能在应用代码很差的时候还能发挥出实验室效果或者接近实验室效果呢。很少吧。我目前看到的例如Oracle in-memory还有tidb的tiflash的设计以及MySQL的heatwave都是从设计上用硬件去抗掉了。这些我真正用过的仅有in-memory,真的是全表聚合一亿条,也就一秒不到。而这个还是我虚拟机效果,不是一体机的效果。所以我觉得真正能抗烂代码的性能才是真的性能。

举报

相关推荐

0 条评论