数据库的读与写探讨

写于之前

本篇文章,主要旨在记录这些时间对数据库(系统)读与写,HA、HP上的一些思考,做一些沉淀。可能会有地方有缺陷,也是为了将来可以更好得提高打下一些思想基础。

读与写

说到系统上的读与写,特别是数据库,不知道大家会首先冒出什么概念,我把自己对这两种操作的关键点理解列一下。
写:事务、落盘
读:缓存、高效
我觉得对于写操作,数据一致性、稳定性毫无以为的关心重点,虽然有点废话,其实我的意思是,写操作主要关心这两点就够了。为什么写不需要做性能优化?因为写操作的性能优化点实在屈指可数,一般而言,我们会做合并批量处理,或者是更新删除的where条件有索引即可。如果是大型系统的写优化,有另外的方式,下面会说到。
对于读操作,这一块,是慢SQL泛滥的地方,因为业务需求,可能会有各种各样的连接嵌套分组查询,而并不是所有的条件都有索引覆盖到,或者是走正确预料之中的索引,需要读SQL做很多的优化。此外,就算有索引,在几百万行记录,高并发查询面前,数据库依然响应会很慢,这时候会把一些数据上浮作缓存,这里不是特定指数据库本身的缓存,可能是系统的缓存Redis、或者是搜索引擎Solr之类的,虽然这可能会牺牲一部分一致性(看需求场景)

数据库系统发展之路

这里先讲一下,我们数据库系统随着公司业务发展的过程。
第一阶段:一台Mysql服务器,业务都在上面,读读写写变化快,定期备份;优点:响应快 缺点:挂得也快
第二阶段:一台Mysql主服务器,多台从服务器,读写分离,异步binlog同步;优点:性能提高 有高可用性了 缺点:写有瓶颈,治标不治本
第三阶段:N台Mysql服务器组,每个组有主从架构,服务器组按照某个维度分库,并且分表;优点:高可用 高性能 缺点:系统处于分布式下,一些分布式的问题就会暴露

分布式下的读与写

从之前的阶段可以看到,我们的数据库以后必然会随着业务发展转向分布式。分布式的确给我们带来了很多好处,但同时也带来了麻烦,现在回头看一下之前读写的特点。
先说写,原来10条数据往一个库一个表写,那分布式下我就可以往10个库10个表各写一条,那么压力就会小很多,而且以后业务量上去了,加机器,加库就行了。但是注意到写一般是具有事务的,现在跨库了,是没有办法保证涉及多库操作的事务一致性的,这时候就需要引入分布式事务了(要么就是记录一些异常,后续做数据补偿)
再说读,原来一条查询语句在一个库查询,那分布式下就可能需要查询10个库(当然如果有分库的Hint,可以直接查),然后做数据的整合返回客户端;这其实就是一个数据访问层的中间件了,想想如果查询语句当中含有“limit,group by,join”等,那做数据整合的工作会很复杂,并且同时还需要保证效率和准确性。

延伸及思考

把数据库抽象成一个系统看,任何一个系统肯定也会面临读与写请求,大部分也会需要考虑相对应的特点,问题及解决方案。最后,我的思考就是任何系统肯定都会碰到问题,任何问题肯定都会有对应的解决方案,任何解决方案都会带来额外的优缺,任何额外的优缺都会去推向业务;所以,某种程度上,我们并不是在解决问题,我们只是在权衡,在取舍符合当前业务利益最大化的那个选择。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>