vlambda博客
学习文章列表

MySQL横向扩展-分库分表解决方案总结

阅读使人充实,讨论使人敏捷,写作使人精确。


 从业务场景看分库分表


互联网行业中,业务场景通常写少读多的情况居多在MySQL的使用前期,读性能大多可以通过SQL优化来解决,但随着业务的持续发展,单纯依靠SQL的查询优化会越来越难以达到业务服务要求。


因此,量级较大的业务场景,MySQL的读压力往往会首先成为系统瓶颈所在。


此时,在数据库层面,DBA通常会建议通过横向扩展备库节点的方式,采用读写分离技术来提升业务系统的读性能、读并发能力。


以上是典型的互联网读写分离需求。


除了这种多见的读瓶颈问题,在大型网站和海量数据的业务场景,数据库常见的性能瓶颈下面的两地问题会更加突出:


一是大量的并发读写操作,导致单库出现负载压力过大;

二是单表存储数据量过大,导致查询效率低下。


该种情况,由于业务的读写请求较高,MySQL在主从之间的数据同步容易引发主从延迟问题。改进的做法是,我们可能会架构设计上,需要敦促业务在写入主库之前最好将同一份数据落到缓存,以避免高并发场景下从从库中获取不到指定数据的情况发生。


如果写压力进一步扩大,并且数据量急剧快速增长,DB写节点即主库就会成为整个系统的瓶颈。在MySQL的日常运营中,如果DB中表和表之间的数据很多没有关系的,或者根本不需要表关联Join操作,我们可以考虑按照业务把不同的数据放到不同的服务器中,即垂直分库或叫垂直切分。


不过需要注意的是,垂直分库无法解决单表数据量过大的问题,由于单一业务的数据信息仍然落盘在单表中,如果单表数据量太大,就会极大地影响SQL执行的性能。


由此,在MySQL应用领域,水平分表也是互联网场景应对高并发、单表数据量过大的解决方案之一。

 

分表在本质上可以概括为业务表在逻辑上公用一个路由结构,物理上分散存储。这就是常说的Sharding分片或者分区。


比如以用户ID字段user_id按照一定策略(hash、range等),表中数据拆分到多个子中(分片或分区),以确保子表中数据量在读写性能可接受的范围内。每个子表的结构都一样,每个表的数据都不一样,没有交集,所有表的并集是全量数据。


水平分表主要用于业务架构无法继续垂直细分、数据库中单张表数据量太大、查询性能下降的场景。


应该使用哪一种方式来实施数据库分库分表,需要从数据库的瓶颈所在和项目的业务角度进行综合考虑。如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、耦合度较低,建议优先使用垂直切分。


如果数据库中的表并不多,但单表的数据量很大且数据热度很高,这种情况之下就应该选择水平切分


在现实项目中,往往是这两种情况兼而有之,综合使用了垂直与水平切分,我们首先对数据库进行垂直切分,然后针对一部分表进行水平切分。


但是,采用分库分表也会引入新的问题。


 分库分表存在的问题及注意点


l 跨库Join问题


分库分表后,表之间的关联操作将受到限制,无法join位于不同分库的表,也无法join分表粒度不同的表,结果导致原本一次查询能够完成的业务可能需要多次查询才能完成。


因此,分库分表的设计,需要结合业务数据的关联场景,适当考虑数据的冗余和拆分策略。比如:根据之前表之间的关系,将相关表以相同的拆分策略,确保关联数据存放到一个分片上。或者使用表级冗余将基础数据在所有库都写一份。使用字段冗余:把需要join的字段冗余在各个表中,这样有些字段就不用join去查询了。再者就是在应用逻辑层进行数据组装:将原来的请求分两次查询,在第一次查询的结果集中找出关联数据id,然后根据id发起第二次请求得到关联数据,最后将获得到的数据进行字段拼装。

 

排序合并问题


由于数据的分库、分片导致的分散存储,原来的业务请求会引发结果集合并、排序问题。尤其是当排序字段不是分片字段的似乎,问题会变得比更加复杂。

需要先在不同的分片节点中将数据进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序,最终返回给用户。


因此,分库分表,还需要考虑业务具体的排序场景,尽量保障排序字段和分布键一致,确保请求通过分片规则就比较容易定位到指定的分片。


迁移和扩容问题


迁移和扩容,属于DB日常运营中常规场景。分库分表后,如果数据采用的是数值范围range分片,那么我们只需要添加节点就可以进行扩容;但如果采用的是数值hash取模分片,由于扩容涉及数据重分布过程,扩容相对比较麻烦。


所以,分库分表,需要根据业务当前、预期的数据量、QPS来进行容量规划,推算

出大概需要多少分片,尽量减少后续扩容及迁移的发生


 分布式事务问题


由于分库分表之后,业务需要跨库跨分片进行SQL请求,类似分布式事务的问题就会出现。为了确保事务的原子性,事务的提交需要协调多个节点,加大事务的执行时间及复杂性。


因此,对于性能要求很高,但对一致性要求不高的系统,在分库分表设计的实时候可能需要采用事务补偿的方式,实时一致性转化为最终一致性,结合业务系统比如对数据进行对账检查、基于日志进行对比等进行事后补偿。


 总 结


分库分表作为一种横向扩展的解决方案,问题还是比较明显的:


  1. 从运维侧来看:会极大的加大系统的复杂度、运维成本相对较高;

  2. 从业务侧来看:会极大增加开发编码工作量,并使业务逻辑复杂化。

  3. 所以,如果无需分片,则尽量避免分库分表;如果确实到了需要分库分表的情况,相对分库分表的通用方案,如果采用分布式中间件或原生分布式数据库,业务侧无需花大量的工作来处理如何分片和分片后的问题,有更多的时间原本该是专注于业务的应用。



 
   
   
 

往期推荐

1.

2.MySQL-

                               

                         ------让学习成为一种习惯-Aken