Skip to content

Latest commit

 

History

History
61 lines (49 loc) · 2.67 KB

数据库设计优化.md

File metadata and controls

61 lines (49 loc) · 2.67 KB

数据库设计优化

1. 分表

  • 按拆分方式分为,
    • 垂直拆分
    • 水平拆分
  • 按存储方式又分为,
    • 库内分表
    • 分库分表

垂直分表

也就是“大表拆小表”,

  • 按业务拆分
  • 针对字段多的表,将不常用、数据较大、长度长的字段拆分成“扩展表”

优点

  • 解决业务数据耦合,便于维护;
  • 避免跨页问题。MySQL 底层是通过数据页存储的,一条记录占用空间过大会导致跨页,造成额外的性能开销。另外数据库以行为单位将数据加载到内存中,这样表中字段长度较短且访问频率较高,内存能加载更多的数据,命中率更高,减少了磁盘IO,从而提升了数据库性能。

水平分表

也叫做 Sharding,针对数据量巨大的单张表(比如:订单表),按照某种规则(Range,Hash 取模等),切分到多张结构相同的表里面去。

分片策略

  1. 范围:id 范围、时间范围
    • 优点
      1. 单表大小可控;
      2. 对分片字段进行范围查询方便;
      3. 便于水平扩展,只需要添加节点即可,无需对其他分片的数据进行迁移。
    • 缺点
      1. 热点数据成为性能瓶颈。例如:按时间字段分片,有些分片存储最近时间段内的数据,可能会被频繁的读写,而有些分片存储的历史数据,很少被查询(热点数据将加重数据库的负担)。
  2. Hash 取模
    • 缺点
      1. 水平扩展不方便。扩容时,需要迁移旧的数据。
  3. 映射:单独有一个表存储映射关系

问题

  1. 全局唯一 ID 问题
  2. 跨节点 join、分页、排序等复杂查询问题
  3. 分布式事务问题
  4. 扩容时的数据迁移问题

如何选择分表方式?

方式 场景
(垂直)库内分表 1. 解决业务耦合
2. 避免 “跨页问题”
(垂直)分库分表 1. 高并发场景
2. 解决单机 IO、连接数瓶颈
(水平)库内分表 1. 解决单表数据量大,查询效率低
(水平)分库分表 1. 高并发和海量数据场景
2. 缓解单机和单库的性能瓶颈和压力

2. 读写分离

主服务器处理写操作以及实时性要求比较高的读操作,而从服务器处理读操作。

优点

  • 主从服务器负责各自的读和写,极大程度缓解了锁的争用;
  • 从服务器可以使用 MyISAM,提升查询性能以及节约系统开销;
  • 增加冗余,提高可用性。

请求分发

读写分离常用代理方式来实现,代理服务器接收应用层传来的读写请求,然后决定转发到哪个服务器。