分库分表
1.数据量太大,SQL查询慢怎么办?
- 从sql语句入手
- exist和in
- in 和 not in
- like
- 从数据库设计入手
- 加索引(不是越多越好)
- 尽量多考虑使用数值型,(性别,int 1,0;不用char 1,0)
- 尽量多考虑使用定长而非变长(idNumber varchar(11))
2.mysql
- 单表存储上限:
(
2
32
)
2
(2^{32})^2
(232)2
- 理论上限,实际上是达不到的:实际行数上限还受myisam_data_pointer_size限制
- 第二个上限是表的存储空间大小限制(Storage limits):256TB
3.千万级别的表查询怎么优化?
-
相关字段加索引
-
优化SQL查询语句
-
不解决,把坑留给后面的接手的客户和程序员
-
加缓存,如:redis,memcached
-
数据库读写分离
-
数据库拆分
4.分库分表,怎么分
-
把原本存储在同一个库的数据分块存储到多个库上,把原来存储在一个表中的数据分块存储到多个表上。
-
分库分表目的:分散单台设备负载
-
常用切分方案:
- A:垂直(纵向)拆分
- 按照不同的表(或者Schema来切分割到不同的数据库(主机)之上)
- B:水平(横向)拆分
- 根据表中的数据的逻辑关系,将同一个表中的数据按照某种条件拆分到多台 数据库(主机)之上。
- C:垂直水平拆分
- A:垂直(纵向)拆分
5.分库分表的解决方案
- 应用层
- 当当[sharding-jdbc],阿里[TDDL]
- Proxy 中间层
- 社区:Mycat(cobar)
- 数字:Atlas,金山:kingshard,百度:heinsberge
- 商业版:Oneproxy,youtube:vitess
- 方案比较
Cobar | TDDL | ShardingJDBC | Mycat | |
---|---|---|---|---|
分库支持 | Yes | Yes | Yes | Yes |
分表支持 | No | Yes | Yes | Yes |
框架类型 | Proxy | 应用集成 | 应用集成 | Proxy |
中间层 | Yes | No | No | Yes |
ORM支持 | 任意 | 多种 | 多种 | 多种 |
数据库支持 | mysql | 多种 | 多种 | 多种 |
外部依赖 | No | Diamond | No | No |
社区活跃度 | 停滞 | 停滞 | 较活跃 | 活跃 |
文档丰富 | Yes | 中等文本 | Yes | Yes |
持续更新 | No | 中等文本 | Yes | Yes |
6.Mycat分库分表原理和实现
-
分片规则和策略 —> 多种分片规则策略,还可以自定义
-
分布式全局唯一ID —> 多种分布式全局唯一ID实现
-
多数据源管理问题 —> 统一管理所有数据源
-
跨域跨表join问题 —> 全局表/sharedjoin/catlet
-
其他特点:
- 独创ER关系分片,解决ER分片难处理问题
- 采用全局分片技术,每个节点同时并发插入和更新数据,都可以读取数据
- 通过人工智能的Caltlet支持分片复杂SQL实现以及存储过程支持等。
-
通俗易懂解析MyCat
- mycat就是一个数据库中间件,数据库的代理,它屏蔽可物理数据,应用连接mycat,然后mycat再连接物理数据库
- 它支持水平拆分(分库分表,通过分库达到分表),支持多种分片规则。比如:范围切片、自然月分片、hash取值分片等
- 它支持mysql、oracle、mongodb、sql server,并支持数据库集群。
-
MyCat核心配置文件
- server.xml 配置连接mycat的用户名、密码、数据库名
- schema.xml 配置schema,datanode,datahost
- rule.xml 分片规则
7.Mycat分库分表后的问题
-
垂直拆分带来的问题:
- 部分业务表无法join,只能通过接口方式,提高了系统复杂度
- 存在单表性能瓶颈,不易扩展
- 事务处理复杂
-
水平拆分带来的问题:
- 拆分规则难以抽象
- 分片事务一致性难以解决
- 维护难度较大
- 跨表join性能差