一后有的节点还是无法负担写负载
不同于MySQL的分区表是在同一个节点中的同一个数据库建立的
而分片后通常是存在不同的物理节点上
由于技术难度极高,难以维护,情非得已,谨慎操作
对一个库中的相关表进行水平拆分到不同实例的数据库中
- 尽量避免跨分区查询的发生(无法完全避免)
- 尽量使各个分片中的数据平均 存储无需分片的表
- 每个分片中存储一份相同的数据
对于数据量不大且并不经常被更新的字典类表,经常需要和分区表一起关联查询,每个分片中存储一份冗余的数据可以更好提高查询效率,维护其一致性就很重要了 - 使用额外的节点统一储存
没有冗余问题,但是查询效率较差,需要汇总 在节点上部署分片 - 每个分片使用单一数据库,并且数据库名也相同
结构也保持相同,和单一节点时的一致 - 将多个分片表存储在一个数据库中,并在表名上加入分片号后缀
- 在一个节点中部署多个数据库,每个数据库包含一个切片
分配分片中的数据
期望尽量平均分配
- 按分区键的Hash值取模来分配分片数据
可以相对平均的分配数据,但是难以人为控制江苏数据分配到哪个分片中 -
按分区键的范围来分配分片数据
常用于分区键为日期或数值类型,可以清楚知道数据被分配到哪个分片中,但易产生分配不均及访问量不均 - 利用分区键和分片的映射表来分配分片数据
前面两种都无人发灵活地控制哪些数据存储在哪些分片中于是有此法
可使用缓存方式读写 映射表,防止成为数据库瓶颈 生成全局唯一ID - 使用
auto_increment_increment和auto_increment_offset服务器变量让MySQL以期望的值和偏移量来增加auto_increment列的值
方法简单,不依赖于某节点,比较普遍采用但需要非常仔细的配置服务器,不适用于一个节点包含多个分区表情况 - 使用全局节点来生成ID
在一个全局数据库节点中创建一个包含auto_increment列的表,APP通过该表生成唯一数字,但该表易成为系统瓶颈 - 在Redis等缓存nosql服务器中创建全局ID
避免了MySQL性能低的问题