直接对一个数据量很庞大的数据表进行查询时,即使添加了索引,查询起来也会很慢的,因实际应用的需要,为了加快查询速度,增加系统性能,通常的做法就是采用数据库表的分割技术(以下称分割技术),分割技术主要有3种类型,即水平分割、垂直分割、库表散列。
基本思想
Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上,从而缓解单一数据库的性能问题。对于海量数据的数据库,如果是因为表多而数据多,这时候适合使用垂直切分,即把关系紧密(比如同一模块)的表切分出来放在一个服务器上。如果表并不多,但每张表的数据非常多,这时候适合水平切分,即把表的数据按某种规则(比如按ID散列)切分到多个数据库(server)上。根据实际情况做出选择,也可能会综合使用垂直与水平切分。
水平分割
什么是水平分割?打个比较形象的比喻,在食堂吃饭的时候,只有一个窗口,排队打饭的队伍太长了,都排成S型了,这时容易让排队的人产生焦虑情绪,容易产生混乱,这时一个管理者站出来,增加多个打饭窗口,把那条长长的队伍拦腰截断成几队。更形象一点的理解,你拿一把“手术刀”,把一个大表猛的切了几刀,结果这个大表,变成了几个小表.
水平分割根据某些条件将数据放到两个或多个独立的表中。即按记录进分分割,不同的记录可以分开保存,每个子表的列数相同。水平切割将表分为多个表。每个表包含的列数相同,但是数据行更少。例如,可以将一个包含十亿行的表水平分区成12个表,每个小表表示特定年份内一个月的数据。任何需要特定月份数据的查询只需引用相应月份的表。
通常用来水平分割表的条件有:日期时间维度、地区维度等,当然还有更多的业务维度。下面我举几个例子来解说一下
案例1:某个公司销售记录数据量太大了,我们可以对它按月进行水平分割,每个月的销售记录单独成一张表。
案例2:某个集团在各个地区都有分公司,该集团的订单数据表太大了,我们可以按分公司所在的地区进行水平切割。
案例3:某电信公司的话单按日期、地市水平切割后,发现数据量太大,然后他们又按品牌、号码段进行水平切割。
水平分割通常在下面的情况下使用:
(1)表数据量很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,加快了查询速度。
(2)表中的数据本来就有独立性,例如表中分别记录各个地区的数据或不同时期的数据,特别是有些数据常用,而另外一些数据不常用。
(3)需要把数据存放到多个介质上。
(4)需要把历史数据和当前的数据拆分开。
水平切分的优点:
①表关联基本能够在数据库端全部完成
②不会存在某些超大型数据量和高负载的表遇到瓶颈的问题
③应用程序端整体架构改动相对较少
④事务处理相对简单
⑤只要切分规则能够定义好,基本上较难遇到扩展性限制
水平切分的缺点:
①切分规则相对更为复杂,很难抽象出一个能够满足整个数据库的切分规则
②后期数据的维护难度有所增加,人为手工定位数据更困难
③应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难
垂直分割
什么是垂直分割呢?打个形象的比喻,一个小公司通过短短几年发展变成了一个跨国大企业,以前的部门架构明显不能满足现在的业务发展,CEO噼里啪啦的把公司分成了财务部、人事部、生产部、销售部门.....,一下子成立了多个部门,各司其职。
你垂直分割表(不破坏第三范式),把主码(主键)和一些列放到一个表,然后把主码(主键)和另外的一些列放到另一个表中。将原始表分成多个只包含较少列的表。如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割。
数据的垂直切分,也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成,我们垂直的将这些数据块切开,然后将他们分散到多台数据库主机上面,这样的切分方法就是一个垂直(纵向)的数据切分。
系统功能可以基本分为以下四个功能模块:用户、群组消息、相册以及事件,分别对应为如下这些表:
1.用户模块表user、user_profile、user_group、user_photo_album
2.群组讨论表grouPS、group_message、group_message_content、top_message
3.相册相关表photo、photo_album、photo_album_relation、photo_comment
4.事件信息表event
模块之间的关系:
1.群组讨论模块和用户模块之间主要存在通过用户或者是群组关系来进行关联。一般关联的时候都会是通过用户id或者nick_name以及group的id来进行关联,,通过模块之间的接口实现不会带来太多麻烦。
2.相册模块仅仅与用户模块存在通过用户的关联。这两个模块之间的关联基本就有通过用户id关联的内容,简单清晰,接口明确。
3.事件模块与各个模块可能都有关联,但是都只关注其各个模块中对象的信息ID,同样可以做到很容易分拆。
所以,我们第一步可以将数据库按照功能模块相关的表进行一次垂直拆分,每个模块涉及的表单独到一个数据库中,模块与模块之间的表关联都在应用系统端通过接口来处理。如下图所示:
通过这样的垂直切分之后,之前只能通过一个数据库来提供的服务,就被分拆成四个数据库来提供服务,服务能力自然是增加几倍了。
垂直切分的优点:
①数据库的拆分简单明了,拆分规则明确
②应用程序模块清晰明确,整合容易
③数据维护方便易行,容易定位
垂直切分的缺点:
①部分表关联无法在数据库级别完成,需要在程序中完成
②对于访问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求
③事务处理相对更为复杂
④切分达到一定程度之后,扩展性会遇到限制
⑤过度切分可能会带来系统过渡复杂而难以维护
库表散列
表散列与水平分割相似,但没有水平分割那样的明显分割界限,采用Hash算法把数据分散到各个分表中,这样IO更加均衡。一般来说,我们会按照业务或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,散列128张表,则应就能够低成本的提升系统的性能并且有很好的扩展性。
在实际应用当中,我们可以根据需要把一个数据量很大的表分割,以达到加快查询速度和提升系统的性能。
小编结语:
更多内容尽在课课家教育!
¥48.00¥180.00
¥199.00
¥798.00
¥199.00
¥29.90
¥48.00¥180.00