ignite affinity key 并置 究竟是个啥?
短信预约 信息系统项目管理师 报名、考试、查分时间动态提醒
先上个pgsql操作的对比,然后引出ignite的并置处理规则
ddl:
drop table student;CREATE TABLE student(sid int PRIMARY KEY ,sname varchar(64), cid int);
drop table course;CREATE TABLE course(cid int PRIMARY KEY ,cname varchar(64));
drop table score;CREATE TABLE score(sid int ,cid int,score int,PRIMARY KEY (sid,cid));
dml:
course表:
cid | cname |
---|---|
1 | yuwen |
2 | shuxue |
3 | yingyu |
student表:
sid | sname | cid |
---|---|---|
1 | zhang | 1 |
2 | wang | 2 |
3 | liu | 1 |
4 | li | 3 |
5 | chen | 3 |
6 | zhao | 3 |
score表:
sid | cid | score |
---|---|---|
1 | 1 | 99 |
3 | 1 | 99 |
2 | 2 | 50 |
4 | 3 | 79 |
dql 查询有成绩的学生信息
SELECT student.* FROM student inner JOIN score ON STUDENT
.sid=score.sid
pgsql结果
sid | sname | cid |
---|---|---|
1 | zhang | 1 |
3 | liu | 1 |
2 | wang | 2 |
4 | li | 3 |
ignite结果
SID | SNAME | CID |
---|---|---|
1 | zhang | 1 |
2 | wang | 2 |
显然,ignite结果不正确,似乎是少了部分结果
ignite 并置:
- ignite的数据是分布式存在的
- join类计算只会在本地的数据集上执行,不会跨节点
因此有两种处理方式:
- 设计时就把具有E-R关系的数据分布在相同的节点,此种方式最优,在设计分库分表时也需要考虑这一点
- 开启并置处理:affinity_key=sid,即是告诉ignite,涉及到这个字段的计算时,需要把数据广播到其他所有节点,由此可见,当表的数据量较大时,性能很差
改写score表的ddl如下:
CREATE TABLE score(sid int(11) ,cid int(11),score int(11),PRIMARY KEY (sid,cid))
WITH "template=partitioned,backups=1,affinity_key=sid" ;
再执行:
SELECT student.* FROM student inner JOIN score ON STUDENT
.sid=score.sid
ignite结果
SID | SNAME | CID |
---|---|---|
1 | zhang | 1 |
2 | wang | 2 |
3 | liu | 3 |
4 | li | 3 |
连序都排好了,你说赞不赞 _
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341