{eval=Array;=+count(Array);}
之前在BAT里参与过一个公司级应用(非市场级,投入的人力也不会那么大),上线2年后,总是被用户投诉,原因是这个应用使用MySql数据库来做持久层,但是2年了,有一张非常重要的存储历史任务的表实在是太大了,导致通过页面想要查询历史数据的速度变得非常非常慢,所以用户很是不满意。
分析下来,这不是用Redis能解决的缓存问题,而是历史数据的查询响应速度问题。
我们最开始是希望能够通过增加索引的方式解决,但是面对千万级别的数据量,我们也不敢贸然加索引,因为一旦数据库hang住,期间的所有数据库写入请求都会被放到等待队列中,如果请求是通过http请求发过来的,很有可能导致服务发生分钟级别的超时不响应。
虽然经常被用户投诉反应慢,也不能破罐破摔,直接超时不响应了吧。
于是我们陷入了两难的境地。
后来我们分了两个部分来优化持久层。
第一步就是配置MySQL的主从库,通过将读写请求分离,来提高数据库的响应速度。
从上图可知,来自同一台服务器的请求,经过MySQL-proxy被分流给了不同的MySQL节点,其中写请求给了主节点,读请求给了从节点。因此,我们首先通过分流的方式,减轻了单节点MySQL的响应压力,实现了优化的第一步。
但是,只配置MySQL的主从是远远不够的。
通过查阅论坛,相关资料,我们最终敲定在持久层引入ElasticSearch。
Elastic Search是一个轻量级的持久层工具,它支持动态多节点部署,自动备份,节点掉线后能够自动切换主从,动态广播发现新上线的节点,而这些优点的应用,无须修改任何server端配置。可以这样理解,如果你部署了4个elastic search节点,其中2个掉了,服务器还是可以很好的继续运行。
此外,它还有一个最重要的优势,那就是支持大数据快速查询。一张几千万的表,如果用MySQL查询,可能需要几秒到几十秒不等,但是如果用elastic search,只需要毫秒级别就能查询到结果。完美的解决了我们当前的问题,还顺带帮我们巩固了持久层的稳定性问题。
综上,优化Mysql的目的是为持久层服务,除了引入主从配置,当MySQL自身局限性导致无法继续优化后,引入其他技术也是十分必要的。
如果你对这篇回答有任何问题,欢迎在下方点赞,留言。
我是苏苏思量,来自BAT的java开发工程师,头像是本人,每天都会分享科技类见闻,欢迎关注我,与我共同进步。
0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答