因为性能问题,对数据表进行了水平切分。切分方案如下:
一个大的用户表user表,按user_id的值进行切分,
user_id%3=0(数据库0)
user_id%3=1(数据库1)
user_id%3=2(数据库2)
user_id被3求模后分别存放到3个数据库中。这样做的好处是减轻了单表大数据量引起的性能问题。但是随之遇到一些问题,
1.对于批量删除有什么好的方案。
1)删除指定user_id范围的数据,比如user_id>302 and user_id<3400;这样的需求如何处理高效,难道必须要循环范围内每个id,然后算出其存放在哪个数据库,然后删除之。或者先在这个范围内统计出3个数据库的id列表,然后执行三次批量删除。总感觉这些方案效率都不高。
2)删除某个条件的数据,比如delete user where user.name like '%ggg%' and .. 这里可能有更复杂的过滤条件。这就比较麻烦了。。
2.对于更新数据有类似删除一样的问题。
1)类似update user set name='aa' where user_id>302 and user_id<3400的处理。
2)类似于删除。。
3.查询问题:
1)根据用户id范围查询,比如select * from user where user_id>302 and user_id<3400
2)根据其他条件查询。以上的这些问题,我想是很通用的问题,任何做数据水平切分处理的时候都会遇到,大家有没有好的解决方案,一起探讨下。
一个大的用户表user表,按user_id的值进行切分,
user_id%3=0(数据库0)
user_id%3=1(数据库1)
user_id%3=2(数据库2)
user_id被3求模后分别存放到3个数据库中。这样做的好处是减轻了单表大数据量引起的性能问题。但是随之遇到一些问题,
1.对于批量删除有什么好的方案。
1)删除指定user_id范围的数据,比如user_id>302 and user_id<3400;这样的需求如何处理高效,难道必须要循环范围内每个id,然后算出其存放在哪个数据库,然后删除之。或者先在这个范围内统计出3个数据库的id列表,然后执行三次批量删除。总感觉这些方案效率都不高。
2)删除某个条件的数据,比如delete user where user.name like '%ggg%' and .. 这里可能有更复杂的过滤条件。这就比较麻烦了。。
2.对于更新数据有类似删除一样的问题。
1)类似update user set name='aa' where user_id>302 and user_id<3400的处理。
2)类似于删除。。
3.查询问题:
1)根据用户id范围查询,比如select * from user where user_id>302 and user_id<3400
2)根据其他条件查询。以上的这些问题,我想是很通用的问题,任何做数据水平切分处理的时候都会遇到,大家有没有好的解决方案,一起探讨下。
不管你你delete/update的数据是否在制定的数据库,都要在这个些数据库中执行一次SQL,如果分的数据库多了可能要牺牲点性能。另外,我突然想起来一个分表的问题:
以前有个项目,在同一个数据库中,对同一表进行分表处理,由于该表数据量相当大,每天都400万数据,这样我们采取的方案是每天生成一个表存储。
这种情况下的删除/更新/查询就比较麻烦,因为不可能对这个N个表都执行一次SQL吧。每天一个表是很多的。
先在删除/更新/查询的范围内统计出3个数据库的id列表,然后执行三次批量SQL,是这样吗,我也只能想到这个办法。但是对于条件不是user_id的处理好像这样就不行。比如类似:where user.name like '%ggg%' and ..
相同处:都是对同一数据表中的数据按一定的分隔规则分成多个数据表保存。
不同处:
1.存放的数据库不一样:
数据水平切分:将分开的数据表放在不同的数据库中。
分表处理:将分开的数据表放在原来的数据库中。
2.数据表的表名处理不同。
数据水平切分:分开的数据表表名跟原来的表名一样。
分表处理:分开的数据表表名不一样,一般以某字段的值的范围命名,如按日期命名,user_20091021
3.选择方案的背景不同:
数据水平切分:一般采取这个方案有2个目的:1)为了解决单表数据量大引起的性能问题,这个与分表的背景一样,2)为了分担单个数据库压力。
分表处理:主要是解决单表数据量大引起的性能问题,而此时整个数据库的压力并不大。以上是本人的个人观点,希望大家一起探讨。