表分区

分区:数据库分区是一种物理数据库设计技术,主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间;

当表中的数据量不断增大,查询数据的速度就会变慢,应用程序的性能就会下降,这时就应该考虑对表进行分区。表进行分区后,逻辑上表仍然是一张完整的表,只是将表中的数据在物理上存放到多个表空间(物理文件上),这些区块可以在同一个磁盘上,也可以在不同的磁盘上,这样查询数据时,不至于每次都扫描整张表

表分区有以下优点:

1、改善查询性能:对分区对象的查询可以仅搜索自己关心的分区,提高检索速度。
2、增强可用性:如果表的某个分区出现故障,表在其他分区的数据仍然可用;
3、维护方便:如果表的某个分区出现故障,需要修复数据,只修复该分区即可;
4、均衡I/O:可以把不同的分区映射到磁盘以平衡I/O,改善整个系统性能;
5、已经存在的表没有方法可以直接转化为分区表;

表分区类型

  • RANGE分区
  • LIST分区
  • HASH分区
  • KEY分区
  • 复合分区

分库

对数据库进行拆分从而提高数据库写入能力,即分库

数据库分库分为垂直分库和水平分库

  • 垂直分库
    按照业务模块来划分出不同的数据库,而不是像早期一样将所有的数据表都放到同一个数据库中;
    垂直切分的依据原则是:将业务紧密,表间关联密切的表划分在一起,例如同一模块的表

  • 水平分库
    将同一个库按照数据的某一维度拆分为多个库

分表

对于访问极为频繁且数据量巨大的单表来说,首先需要减少单表的记录条数,以便减少数据查询所需要的时间,提高数据库的吞吐,这就是分表;

使用场景:单表数据量非常庞大且访问频繁

分表包含垂直分表

  • 垂直分表
    垂直分表在日常开发和设计中比较常见,通俗的说法叫做“大表拆小表”,拆分是基于关系型数据库中的“列”(字段)进行的。通常情况,某个表中的字段比较多,可以新建立一张“扩展表”,将不经常使用或者长度较大的字段拆分出去放到“扩展表”中

  • 水平分表
    水平分表也称为横向分表,比较容易理解,就是将表中不同的数据行按照一定规律分布到不同的数据库表中(这些表保存在同一个数据库中),这样来降低单表数据量,优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分

分库&分区&分表

分区:主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间;
分库:降低了单点机器的负载(主要解决写入问题和物理IO性能瓶颈);
分表:提高了数据操作的效率(解决单表查询性能)

分库分表的难点

跨库join的问题

在拆分之前,系统中很多列表和详情页所需的数据是可以通过sql join来完成的。而拆分后,数据库可能是分布式在不同实例和不同的主机上,join将变得非常麻烦。而且基于架构规范,性能,安全性等方面考虑,一般是禁止跨库join的

  1. 字段冗余
    这是一种典型的反范式设计,在互联网行业中比较常见,通常是为了性能来避免join查询;
    举个电商业务中很简单的场景:
    “订单表”中保存“卖家Id”的同时,将卖家的“Name”字段也冗余,这样查询订单详情的时候就不需要再去查询“卖家用户表”。
    字段冗余能带来便利,是一种“空间换时间”的体现;
    缺点是冗余的数据如何更新;

多维度查询问题

  1. 分库分表拆分维度
    比如针对订单的分库分表,分库和分表的拆分以userId进行拆分,那么用户维度的查询订单请求没有问题(根据userid进行hash路由);如果以订单为维度的查询呢,那么可以在订单号上做文章,订单号以用户末4位开头,这样以订单号为维度查询时,先取订单号上的userId,然后根据userId进行路由;

  2. 使用mapping关联表
    还是以订单为例,分库分表以订单号为维度进行拆分,但是建立订单号和userId的mapping表,当需要查询某个用户的订单的时候,先查询mapping表;
    缺点:mapping表可能会成为新的瓶颈

  3. 数据异构
    订单的分库分表以订单为维度拆分,同时同步复制订单数据到另一个库,以用户ID进行拆分,当查询用户的订单信息时直接查另一张用户维度的订单表;数据的同步可以采用数据同步的一些中间件,比如canal/databus等;

分页与复杂查询问题

  1. 数据库分库分表后分页与复杂查询建议不走在数据库查询,可以走搜索引擎;

【总结】

  • 并非所有表都需要水平拆分,要看增长的类型和速度,水平拆分是大招,拆分后会增加开发的复杂度,不到万不得已不使用。
  • 在大规模并发的业务上,尽量做到在线查询和离线查询隔离,交易查询和运营/客服查询隔离。
  • 拆分的维度的选择很重要,要尽可能在解决拆分前的问题的基础上,便于开发。
  • 数据库没你想象的那么坚强,需要保护,尽量使用简单的、良好索引的查询,这样数据库整体可控,也易于长期容量规划以及水平扩展。

【参考资料】数据分库中间件

sharding-jdbc ##当当网
Atlas ## 360
mycat ## 开源社区
DBProxy ## 美团
dbsplit ## github上有开源

链接
https://dbaplus.cn/news-10-264-1.html

results matching ""

    No results matching ""