复制表+分布表
- 应用发出查询数据SQL;
- CN根据查询条件判断包含复制表和分布表,则分别向HG-1、HG-2、HG-3查询数据,并获得每个节点上的结果;
- 合并结果并返回。
这类查询性能较高,高并发的支持不如只涉及单组情况,适于大表的存储。
-
-
- 分布表+分布表
-
分布表+分布表的查询,分为数据落在相同HG上和不同HG上两种类型。
数据落在相同HG上时原理如下:
TD1和TD2皆为分布表,以uid为分片列:
- CN接收到SQL后,根据集群元数据存储的分片规则,确认此次查询仅涉及HG-1;
- 把SQL语句直接发送给HG-1,获得执行结果;
- CN将结果返回给用户。
这类查询性能高,无冗余操作,支持高并发,性能线性提升。
数据落在相同HG上时原理如下:
TD1和TD2皆为分布表,以uid为分片列:
- CN接收到SQL后,根据集群元数据存储的分片规则,根据TD1表的分片规则,生成分布SQL语句;
- 把SQL语句发送给HG-1数据引擎执行;
- HG-1拉取其他HG上TD2表uid<60的数据;
- 进行JOIN查询计算;
- HG-1将结果返回给CN;
- CN返回给用户。
这类查询性能较差,涉及数据移动,跨节点拉数据,网络传输是瓶颈。
GBase 8c具备全局死锁解除的能力。当发现死锁情况时,会将全局事务号最大的事务退出,从而解决死锁问题。
GBase 8c通过在CN和DN上部署global deadlock process并与GTM建立通讯通道,周期性的对事务等待关系进行检测,并将检测结果发送给GTM用来构建全局等待图。当检测到死锁环时,立即将执行事务号最大的事务执行退出流程,从而解决全局死锁问题。
GBase 8c具备事务状态保持能力,任意协调器节点(CN)宕机后,都不影响该节点正在进行的事务状态,事务可以在另一接管CN节点上继续顺利运行,从而保证数据库处理能力。
如上图所示两阶段提交事务处理过程中:
- CN2节点正常下发事务Prepare状态;
- 三个DN节点正常返回事务Prepare OK状态;
- CN2节点正常下发事务Commit状态;
- DN1节点返回Commit OK状态且DN2、DN3还未完成Commit OK状态提交时,CN2节点宕机;
- 此时CN3节点检测到CN2节点宕机,会自动接管CN2未完成的事务和状态;
- DN2、DN3节点重新提交Commit OK状态至CN3节点,并完成该两阶段提交过程。
CN3节点接管事务后,无需重复前面已经成功提交的事务状态,可以继续完成宕机的CN2节点未完成的状态来完成本次事务。整个过程对上层业务无感知,数据库集群内任意节点宕机均不会造成死锁或异常等待情况。
海量的业务数据不仅仅给数据处理和分析查询的性能带来挑战,对数据备份和恢复的要求也更高。因为数据量巨大,如果没有高效的备份和恢复能力,在意外、故障或灾难发生时,无法及时使数据库得到恢复,系统和业务的可用性就无法得到保障。
GBase 8c提供全面的基于集群级、库级、表级的备份和恢复功能,包括:
- 全量备份和恢复;
- 增量备份和恢复:允许基于任意一个备份点进行数据恢复。