欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Freyja2版本对分库分表的处理方式

程序员文章站 2022-03-06 20:37:41
...

在freyja2里面,对于数据库sharding这方面一张表需要设定一个切分的key列

假设UserProperty 里面有 id,uid,pid,num这4个字段,uid为用户id。我们把这张表以uid来切分

数据库设定为2个, 表切分为5个/库。

db_0,
t_user_0,t_user_1,t_user_2,t_user_3,t_user_4

t_user_property_0,t_user_property_1,t_user_property_2,t_user_property_3,t_user_property_4


db_1,
t_user_0,t_user_1,t_user_2,t_user_3,t_user_4

t_user_property_0,t_user_property_1,t_user_property_2,t_user_property_3,t_user_property_4
 

 

 

freyja2屏蔽了上层分库、分表逻辑

 

在开发过程中,insert、update、select、delete操作和非sharding 项目没有任何差别

 

insert一条user记录,

insert user(name)values(?)

 

如果user是以name列为切分的key列,那么name为?的这条记录会被分配到

 

	public DbResult getShardingTableName(Object value) {
		String tableName = getTableName();

		int hashCode = value.hashCode();
		if (hashCode < 0) {
			hashCode = -hashCode;
		}
		int dbNo = hashCode % ShardingUtil.engine.getDbNum();
		int tableNo = hashCode % ShardingUtil.engine.getTableNum();
		tableName = tableName + "_" + tableNo;
		return new DbResult(tableName, tableNo, dbNo);
	}

 

 dbNo数据库的tableNo表

这个时候user的主键:id为自动增长,自然获得了一个对应的id值。那么在查询的时候,

 

无论是select * from User where id = ? 还是 select * from User where name = ?

   

 

都能够找到其所在的dbNo 和tableNo

 

idSubNum 为每个表的容量

 

 

	public DbResult getShardingTableNameById(Object idValue) {
		String tableName = getTableName();
		if (idValue == null || !isSubTable()) {
			return new DbResult(tableName, -1, -1);
		} else {
			int n = (Integer) idValue / ShardingUtil.engine.getIdSubNum();
			int dbNo = n / ShardingUtil.engine.getTableNum();
			int tableNo = n % ShardingUtil.engine.getTableNum();
			tableName = tableName + "_" + tableNo;
			return new DbResult(tableName, tableNo, dbNo);
		}

	}
 

 

单表的sharding就不多说了,联表查询?

假设有原有这样的一条查询sql:

select * from t_user_property p left join t_user u on p.uid = u.id where u.name = ?
 

对于sharding之后的应用来说 sql当然不能这样写。

 

前面说了2点:

1、freyja2是屏蔽上层sharding逻辑的。

2、user的name和id对应的是同一张表、库

 

在freyja2的处理里面,sql还是按照这样写,根据逻辑freyja根据name的值解析出了user所在的dbNo和tableNo

重新生成sharding的sql(假设tableNo为3,dbNo的作用在于找到对于的数据源):

 

 

 

select * from t_user_property_3 p left join t_user_3 u on p.uid = u.id where u.name = ?
t_user_property 这个表因为也是以uid来分库的,所以其对应的表和库实际上与t_user是一致的。

 

 

有2种复杂一点的情况:

1、单表查询不包括key列

2、联合查询以非key列为join列

 

对于第一种情况,freyja会扫描所有的库、表汇总一个结果集返回来 例如:

 

select * from t_user where gold > 0
会变为
db_0:
select * from t_user_0 where gold > 0;
select * from t_user_1 where gold > 0;
select * from t_user_2 where gold > 0;
select * from t_user_4 where gold > 0;
db_1:
select * from t_user_0 where gold > 0;
select * from t_user_1 where gold > 0;
select * from t_user_2 where gold > 0;
select * from t_user_4 where gold > 0;
 

对于第二种情况:

 

第二种情况比较少见,不可能跨数据源查询。一般既然分库,key列就成为了关键列。所有sql都要围绕着这个列,处理起来需要进行一些变通,暂时没有深挖这部分sql的处理

 

至于排序、分页存在一种情况:就是非key列的查询,sql中如果带有key列那么排序、分页实际上就是普通的查询一样,数据库来做。但是一旦需要扫描整个库,排序和分页是需要freyja2在返回结果集的时候处理的

 

 

在项目里面分出了2个库一共有3个库:db,db_0,db_1 db0和1是存储需要分库的表 db则放置不需要分库的表,毕竟不是每个表都要去分库的。

 

 

 

至于数据迁移和扩容,这部分还未想出比较好的方法。

sharding这部分我一直都认为这是数据库分内的事,应该可以把freyja的sharding这部分再提取出来放在驱动一层上,更加的脱离业务