MySQL vs Redis,新时代王者的较量
最近海贼王的漫画连载中,五位新时代的超新星正联手对付两位四皇,旧时代的霸主。
曾经被作者无数次铺垫的地球最强生物凯多,先是被索隆用九刀流砍伤,接着又被领悟霸王色缠绕的路飞打得口吐鲜血。不用往下看,接下去主角路飞肯定能打败地球最强生物。
在数据库领域Oracle毫无疑问是曾经的王者,地球最强数据库。但进入新时代后,超新星的诞生正在不断挑战旧秩序时代的霸主。不可否认,My + 的组合已经是互联网行业的标准数据库配置,而Oracle数据库已逐渐黯然失色。
MySQL好比是海贼王中的路飞,Redis就是他的副船长索隆。之前MySQL vs Memcached的文章中,不少同学留言想要看MySQL vs Redis的性能跑分。今天,安排~~~
对决,MySQL vs Redis!
熟悉Redis架构的同学应该知道Redis是单线程的,这里的单线程是指核心执行KV操作是单线程的。因此,理论上来说1个Redis实例只能跑在1个CPU上。
所以,从测试上看,Redis是非常吃亏的,也是我之前并不像对比Redis的原因。
接下去我们开始进行测试,测试过程中Redis关闭aof,rdb功能,作为纯内存KV进行GET、SET请求。
MySQL这里启用Memcached Plugin插件,使用Memecache的GET、SET请求。
下表显示了GET测试的结果:
可以看到随着线程数的增大MySQL的GET性能不断提升,可以充分利用CPU的多核性能。
相反,Redis较高只能维持在单个CPU的使用,因此较高也只能有16W左右的QPS。而我们已经在前面的文章中知道这台服务器MySQL的GET上限是280W的QPS。
所以,16线程以上不用再测试了,否则对Redis侮辱性太强。
接下去的SET测试结果是大同小异,但是需要特别提醒的是Redis的CPU占用率只有100%,而MySQL在16个线程下的测试,CPU使用率有1506%,比Redis要高15倍。
当然,这也是因为MySQL需要事务支持,日志写入等额外开销。
Redis,yyds
在这一场对决中,我们并不能说Redis完败MySQL,相反Redis表现的及其优异。
因为MySQL单核CPU只有7W的效率,而Redis可以有15W的效率。
这是两种完全不同数据库应用导致的不同架构。MySQL关系型数据库会尽可能充分挖掘多核性能,不断满足业务的QPS。
Redis最初的定位就只是一个缓存,所以,缓存真的需要百万QPS么?在真实的架构中,其实并不需要。
很多人认为KV数据库性能比基于磁盘的关系型数据库好,其实大部分是错的。或者说理解是非常片面的。从跑分来看,无论是Redis、还是Memached,都输给了MySQL数据库。
但我依然认为Redis是新时代的王者,因为他解决业务环节的真正痛点:理解并支持业务所需的数据结构,提升软件开发效率。
什么RT(Response Time)时间更低,性能更好,全部是错的,彻头彻尾的错误!!!完全经不起推敲。
Redis只做对了一件事情,所以他把Memcached干掉了。不是因为性能,而是因为他更懂业务。
为什么曾经的王者Oracle数据库终将败给新时代的数据库们呢?
因为类似MVCC、RAC这样雷鸣八卦般的绝招,数据库的新星们都有其他更优的解决方案。
与此同时,MySQL和Redis更贴近业务的需求,在数据库层做减法,做精做细自己所擅长的部分,而不是一味地堆叠无用的功能和硬件。
对于国产数据库的思考
通过MySQL、Redis数据库超新星们的成功,再来review当前的国产数据库们。
他们无一例外犯了一个错误,那就是:做大做强。丧失了对于业务真正需求的理解。
银行在去IOE的过程中真的需要分布式数据库么?
业务真的需要分布式全局MVCC功能么?
业务真的需要分布式数据库的分布式事务机制么?
又比如某分布式数据库,竟主打用一堆超高配置硬件做数据库架构,只是为了在不足1000的QPS业务上实现所谓的动态扩缩容功能。
为什么就没有人能做一个国产的缓存系统呢?大家都需要,能真正提升开发效率的产品呢?然后在此基础上不断迭代,成为的缓存产品。
而不是拿着MySQL协议在上面包着一层又一层,甚至把LevelDB的KV结构硬生生的封装出了关系型结构。
这里,我强烈推荐腾讯互娱团队开发的Tendis数据库产品。100%兼容Redis协议、高可用、高性能、可持久化的分布式高性能KV数据库。
可能有同学会认为他们只是在Redis源码上进行了持久化功能的微创新,但实际是他们团队用近3年时间全新开发的这款KV产品。
可以说,这是最近几年我见过最贴近业务的数据库产品,而不是一帮内核开发人的闭门造车。
Tendis数据库目前已开源,感兴趣的同学可关注GitHub:https://github.com/Tencent/Tendis
声明:文章收集于网络,版权归原作者所有,为传播信息而发,如有侵权,请联系小编删除,谢谢!
时间:2021-06-06 23:50 来源: 转发量:次
声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。
相关文章:
- [数据挖掘]在复杂条件搜索上,为什么MySQL只能被ES吊打?
- [数据挖掘]MySQL 8.0的Public Key Retrival错误,毫无规律可言怎么
- [数据挖掘]吊打MySQL,MariaDB到底强在哪?
- [数据挖掘]Redis 日志篇:无畏宕机实现高可用的杀手锏
- [数据挖掘]如何从0到1构建稳定、高性能Redis集群?
- [数据挖掘]Redis为什么变慢了?常见延迟问题定位与分析
- [数据挖掘]分布式锁用Redis好?还是Zookeeper好?
- [数据挖掘]为什么阿里不建议MySQL使用text类型?
- [数据挖掘]“MySQL Analytics Engine”来了
- [数据挖掘]惊了! MySQL 热冷数据分离设计还能这样!
相关推荐:
网友评论:
最新文章
热门文章