当前位置: 首页 > 科技观察

MySQL读多写少的设计方案——分库分表还能这样吗?

时间:2023-03-13 16:12:11 科技观察

本文转载自微信公众号《JerryCodes》,作者KyleJerry。转载本文请联系JerryCodes公众号。通过主从复制技术将数据复制多份,读操作只读从库中的数据,增强了抵抗大量并发读请求的能力,提高了数据库的查询性能。此时你的系统架构如下:系统架构图案例背景如何判断是分库还是分表?什么时候分表,什么时候分库?VerticallysplitRange(rangefragmentation)如何解决数据查询问题?后台,面试官问了一道测试题:公司现有业务持续发展,流量激增,交易笔数突破千万级订单,但订单数据仍然存储在单表中。主从分离后,虽然减轻了读请求的压力,但是随着写压力的增加,数据库的查询和写入性能在下降。这个时候你是怎么设计架构的?这个问题可以概括为:对数据库的写请求过多,导致系统出现性能和可用性问题。为了解决这个问题,可以对存储的数据进行分片。常见的方式是“分库分表”。实现策略有垂直拆分、水平拆分、纵横拆分三种。真的可以这样回答吗?分库分表的技术方案虽然很常见,但是在面试中回答好也不是一件容易的事情。因为面试官不会简单粗暴地问你“分库分表的思路”,而是会站在业务场景,当数据出现写多读少的时候,审视你的整体设计方案和技术对于分库分表实现的落地思路。一般会涉及到几个问题:数据库应该划分成什么样的场景?分表应该分什么场景?复杂业务如何选择分片策略?确定分库还是分表?”问题,需要结合具体场景。何时分表当数据量过大,事务执行缓慢时,就要考虑分表了,因为减少每次查询的数据总量是解决数据查询慢的主要原因。你可能会问:“查询可以通过主从分离或者缓存来解决,为什么还要分表呢?”但是这里的查询指的是事务中的查询和更新操作。为了应对高并发,当一个数据库实例无法支持分库时,即单个数据库的性能无法满足高并发的要求,于是将并发请求分发给多个实例(这种处理方式高并发之前我也说过Pass)。一般来说,分库和分表的使用场景是不一样的:分表是因为数据量比较大,导致事务执行慢;分库是因为单个数据库的性能不能满足要求。如何选择分片策略?明确了分库分表的场景后,面试官一般会问“如何分片?”换句话说,应该使用什么样的分片策略来分片数据库?垂直拆分垂直拆分是根据数据的业务相关性进行拆分。比如一个数据库中既有产品数据又有订单数据,垂直拆分可以将产品数据放入产品库,将订单数据放入订单库。一般来说,垂直反汇编往往伴随着系统架构的调整。垂直拆分比如在对系统的“微服务”进行改造时,将原来单一的系统拆分成多个子系统,每个系统提供独立的服务。那么随着应用层面的拆分,还有数据层面的拆分。拆分,将一个主库的数据表拆分成多个独立的子库。数据库垂直拆分最为常见,优缺点也很明显。垂直拆分可以隔离不同的业务数据,让系统和数据更“纯粹”,更有利于架构扩展。但是,仍然无法解决某项业务的海量数据扩容问题。一旦系统中某个业务数据库的数据量激增,比如商品系统接入了一个大客户的供应链,商品数据的存储需求就会爆发。这时候就需要将数据拆分到多个数据库和数据表中,也就是将数据进行水平拆分。水平拆分和垂直拆分是随着结构改造进行拆分,侧重于业务领域,而水平拆分是指将单个数据库表的数据按照规则拆分到多个数据库和多个数据表中,比如拆分单个表。1亿条数据按照Hash取模拆分成10张结构相同的表,每张表包含1000万条数据。并且拆分表可以存储在不同的物理数据库中,重点是数据扩展。Range(范围分片)是按照某个字段的区间进行拆分的。最好的理解就是按照时间字段来分片。比如可以把一个月的数据放到一个表中,这样在查询的时候就可以根据时间定位到数据存储在哪个表中,然后根据查询条件进行查询。但是按时间域进行范围分片的场景并不多,因为会导致数据分布不均。毕竟,不是每个月的销售额都是平均的。所以常见的Range分片都是基于字段类型的,比如按照商品的类别分片。这样,与Hash分片不同,Range分片可以增加业务预估。Rangesharding但同样的,因为不同的“商品品类”有不同的业务热点,商品数据存储也会存在热点数据问题。这个时候,有两种方法可以对付他们。1.纵向扩展由于Rangesharding是一种基于业务特性的分片策略,可以对热点数据进行纵向扩展,即提高单机的处理能力。在业务快速发展的初期,建议采用“增强单机硬件性能”的方式来提升系统处理能力,因为在这个阶段,公司的策略往往是发展业务来抢占时间,而“提升单机硬件性能”是最快的方法。2.碎片化的元数据单机性能总是有极限的。互联网分布式架构设计中高并发的最终解决方案是水平扩展。因此,结合业务特点,有必要在Range的基础上引入“分片元数据”的概念:分片规则记录在一张表中。每次执行查询时,先去表中查看你要找的数据在哪个分片中。这种方式的优点是灵活性高,分片规则可以随着业务的发展随意改变.比如当某个shard已经是热点时,可以将该shard拆分成多个shard,或者将这个shard的数据移动到其他shard,然后修改shard元数据表。数据重分片可以在线完成。分片元数据,但是要注意,分片元数据本身需要高可用。该方案的缺点是实现复杂,需要二次查询,需要保证碎片化元数据服务的高可用。然而,片段元数据表可以通过缓存来加速。垂直和水平拆分是一种将垂直和水平拆分方法相结合的混合方法。垂直拆分将不同类型的数据存储在不同的库中,结合水平拆分,使单个表的数据量保持在合理的范围内。提高性能。纵横拆分如何解决数据查询问题?分库分表引入的另一个问题是数据查询的问题(比较常见)。比如面试官会问类似的问题:在数据库分表之前,我们查询数据的总数,可以直接使用SQL的count()命令。现在数据被分散到多个数据库表中。如何解决?有很多方法可以解决这个问题。您可以考虑其他存储解决方案。比如在频繁使用聚合查询时,将聚合查询的数据同步到ES,或者将统计出来的数据单独存放在一个表中。如果是每天定时产生的统计报表数据,也可以将数据同步到HDFS,然后利用一些大数据技术来生成报表。总结一般情况下,当面临数据库容量瓶颈和大并发写入请求时,可以选择垂直分片和水平分片:垂直分片一般伴随着业务架构??拆分进行;水平分片通常根据Hash(哈希分片)取模和范围(rangesharding)进行,通常的形式是垂直分片伴随水平分片,即根据业务垂直分片后,水平分片根据数据块的数量。哈希分片是互联网中使用最广泛的。简单易实现,可以保证数据均匀分布到多个分片上。但是过滤掉了业务属性,不能根据业务特性进行调整。但是,Rangesharding可以更高效地预测业务和扫描数据记录(Hashsharding由于数据碎片化,扫描操作的I/O开销更大)。除了Hash分片和Range分片之外,更灵活的方法是基于分片元数据。但是需要注意的是,这些方法也会引入聚合查询等问题。解决聚合查询,可以将聚合查询记录存储在其他存储设备(如ES、HDFS)中。