分表分库规则
图源(https://zhuanlan.zhihu.com/p/535713197)
水平分表
水平分表一般是我们数据库的数据太多了,原大众点评的订单单表早就已经突破两百G。
数据量太多的影响
1. 查询性能下降:随着数据量的增加,查询的响应时间可能会显著增加,尤其是当查询未使用索引或查询涉及大量数据扫描时(全表扫描)。这会导致查询的执行时间变长,甚至超时。
全表扫描的代价,数据库是按照页为单位,每次加载16kb到内存,加载的数据越多之前的数据查询的缓存按照LRU驱逐出去,导致整个库表查询耗费cpu,内存以及磁盘IO性能达到了极大的影响。
2. 索引维护成本增加:随着数据量的增长,索引的维护成本也会增加。插入、更新和删除操作将变得更加耗时,因为需要同步更新索引。
3. 磁盘I/O增加:大量数据会导致磁盘I/O操作频繁增加。这会进一步影响数据库的整体性能,尤其是在没有足够的内存来缓存常用数据的情况下。
4. 表锁和行锁竞争:在高并发环境中,表锁和行锁的竞争可能会导致事务等待时间增加,影响整体吞吐量。
5. 内存使用增加:数据库引擎可能需要更多的内存来处理大数据量的操作,如果内存不足,系统可能会频繁使用磁盘作为虚拟内存,进一步降低性能。
水平分表分库规则
1,按照时间范围分表
时间范围分表这个比较常见,业务主要是以时间为维度的区分,这样比较高效
2,按照一致性hash进行分表 (采用mod 2^n 一致性Hash)
在大众点评分库分表实践中,C端用户个人UserID后四位进行订单表分库分表,按照一致性hash ,对UserID进行mod32分到32个库里,分好库之后再按照将UserID后四位除以32 ,再Mod 32进行分表(防止数据倾斜)。这样达到1024张表。
单表容量达到上限后,因为UserID后四位取值范围0000 到 9999,选择一个可以分成最大8192(即 2^13)个表的范围来分配数据。因为已经是2^5 mod32来进行分表,我们可以最大扩容2^6到2^13次方。例如,你可能会将 UserID 后四位的值对 8192 取模,这样可以将数据均匀分配到 8192 个表中。
什么时候分库
当物理存储、内存、IO、CPU都出现了瓶颈
垂直分表分库规则
1,将大表拆为小表(按照业务类型)
2,按照数据更新频率,将数据库拆为哪些字段更新频率比较高,每次更新一起批量更新表其他字段属性,降低锁表字段,进而降低锁性能影响
什么时候分库
当物理存储、内存、IO、CPU都出现了瓶颈
引用
https://zhuanlan.zhihu.com/p/482549860