zoukankan      html  css  js  c++  java
  • cockrachdob,tibd怎么处理多表join?--未完结

    cockrachdob,tibd怎么处理多表join?
    同样,mysql用了mycat做了分片之后,怎么做多表join,单表查询是OK的~

    mycat分布式事务解决方案

    准备阶段:事务协调者(事务管理器)给每个参与者(资源管理器)发送准备消息,每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的redo和undo日志但不提交,可以进一步将准备阶段分为以下三个步骤: 1)协调者节点向所有参与者节点询问是否可以执行提交操作(vote),并开始等待各参与者节点的响应。
    2)参与者节点执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入日志。 3)各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个”同意”消息;如果参与者节点的事务操作实际执行失败,则它返回一个”中止”消息。

    提交阶段:如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息,否则发送提交(Commit)消息,参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。 二阶段提交所存在缺点的: 1)同步阻塞问题,执行过程中所有参与节点都是事务阻塞型的,当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。
    2)单点故障,由于协调者的重要性一旦协调者发生故障参与者会一直阻塞下去。 3)数据不一致,在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求,而在这部分参与者接到commit请求之后就会执行commit操作,但是其他部分未接到commit请求的机器则无法执行事务提交,于是整个分布式系统便出现了数据不一致性的现象。

    mycat不适用场景

    1.非分片字段查询 如果该分片字段选择度高,也是业务常用的查询维度,一般只有一个或极少数个DB节点命中(返回结果集)。示例中只有3个DB节点,而实际应用中的DB节点数远超过这个,假如有50个,那么前端的一个查询,落到MySQL数据库上则变成50个查询,会极大消耗Mycat和MySQL数据库资源。

    2.分页排序 但Mycat向应用返回的结果集取决于哪个DB节点最先返回结果给Mycat。如果Mycat最先收到DB1节点的结果集,那么Mycat返回给应用端的结果集为 [0,1],如果Mycat最先收到DB2节点的结果集,那么返回给应用端的结果集为 [5,6]。也就是说,相同情况下,同一个SQL,在Mycat上执行时会有不同的返回结果。

    3.任意表JOIN 无法跨库join
    --那如何仅在分库中join这个结果肯定有问题?

    https://www.cnblogs.com/langfanyun/p/12567355.html
    Mycat 中的 JOIN

    性能建议:
    尽量避免使用 Left join 或 Right join,而用 Inner join 在使用 Left join 或 Right join 时, ON 会优先执行, where 条件在最后执行,所以在使用过程中,条件尽可能的在 ON 语句中判断,减少 where 的执行。
    少用子查询,而用 join。

    Mycat 目前版本支持跨分片的 join,主要实现的方式有四种:全局表, ER 分片, catletT(人工智能)和 ShareJoin, ShareJoin 在开发版中支持,前面三种方式 1.3.0.1 支持 。
    ER的方式很巧妙,但是如果有多个关系怎么处理?

    1)全局表
    一个真实的业务系统中,往往存在大量的类似字典表的表格,它们与业务表之间可能有关系,这种关系,可以理解为“标签” ,而不应理解为通常的“主从关系” ,这些表基本上很少变动。

    考虑到字典表具有以下几个特性:
    • 变动不频繁
    • 数据量总体变化不大
    • 数据规模不大,很少有超过数十万条记录。
    鉴于此, MyCAT 定义了一种特殊的表,称之为“全局表” ,全局表具有以下特性:
    • 全局表的插入、更新操作会实时在所有节点上执行,保持各个分片的数据一致性
    • 全局表的查询操作,只从一个节点获取
    • 全局表可以跟任何一个表进行 JOIN 操作

    2)ER Join
    MyCAT 借鉴了 NewSQL 领域的新秀 Foundation DB 的设计思路, Foundation DB 创新性的提出了 Table Group 的概念,其将子表的存储位置依赖于主表,并且物理上紧邻存放,因此彻底解决了 JION 的效率和性能问题,根据这一思路,提出了基于 E-R 关系的数据分片策略,子表的记录与所关联的父表记录存放在同一个数据分片上。

    customer 采用 sharding-by-intfile 这个分片策略,分片在 dn1,dn2 上, orders 依赖父表进行分片,两个表的关联关系为 orders.customer_id=customer.id。于是数据分片和存储的示意图如下

    3)ShareJoin 是一个简单的跨分片 Join,基于 HBT 的方式实现。类似于redistribution:
    目前支持 2 个表的 join,原理就是解析 SQL 语句,拆分成单表的 SQL 语句执行,然后把各个节点的数据汇集

    4)catlet(人工智能)
    mycat 提供了一些接口,需要自己定逻辑怎么把不同分片的表 join 起来。

    4.分布式事务 Mycat并没有根据二阶段提交协议实现 XA事务,而是只保证 prepare 阶段数据一致性的 弱XA事务

  • 相关阅读:
    poj 3096 Surprising Strings (set)
    hdu 4038 stone
    STL set 使用总结
    poj 3185 The Water Bowls (bfs 加未压缩)
    QPixmap显示图片
    addStretch的作用 .
    Qt SizeHint()
    StyleSheet
    linux编程守护进程编写
    Qt样式表的使用
  • 原文地址:https://www.cnblogs.com/kuang17/p/13535657.html
Copyright © 2011-2022 走看看