分库分表,做到永不迁移数据和避免热点的方法

  1. 云栖社区>
  2. 博客>
  3. 正文

分库分表,做到永不迁移数据和避免热点的方法

程序狗狐狸 2019-08-01 11:23:04 浏览366
展开阅读全文
分库分表,做到永不迁移数据和避免热点的方法:
    基础:
      1、数据拆分方式:垂直拆分,水平拆分。
      2、垂直拆分:原来就一个数据库,数据量一大了,就拆分为多个数据库。
      3、水平拆分:原来是t_order表,拆分成t_order_1、t_order_2、t_order_3、t_order_4。
      4、Mysql单表存储推荐是百万级,尽量别到千万级。
    分库分表方案:
      1、常用的方案:hash取模、range范围方案,分库分表方案最主要的就是路由算法,把路由的key按照指定的算法进行路由存放。        
      2、hash取模方案(无热点问题,扩容困难)
          (一)、首先预估一下总数据量m,设定每张表的最大数据量n,m/n=z 是表个数。
          (二)、hash方案就是对指定的路由key(如:id)对z进行取模,"t_order_"+id%z 是表名字。
          (三)、优缺点:优点是数据均匀的分布在每张表中,不会有热点问题;缺点是数据的迁移或者扩容会很麻烦。
      3、range范围方案(不需要迁移数据,有热点问题)
          (一)、range方案是以范围进行数据拆分:id=50在0~1000的在t_order_0表、id=1050在1000~2000的t_order_1表等。
          (二)、优缺点:优点是扩容方便,不需要数据迁移;缺点是id在0-1000时,t_order_0会很忙,t_order_1,t_order_2...t_order_n...都没有数据的访问,一段时间只有一个热点表。
      4、range和hash组合方案
          (一)、设计是比较简单的,就三张表,把group,db,table之间建立好关联关系。
          group表字段:group_id,group_name,start_id,end_id
          db表字段:db_id,db_name,group_id,hash_value
          group和db的关系表字段:table_id,table_name,db_id,start_id,end_id
          
  分库分表就会带来各种join组合条件的分页查询问题,怎样解决分页查询问题,很有挑战性。   
  
  1.事务问题:
    (1)、分布式事务 (2)、通过应用程序与数据库共同控制实现事务
          方案一:使用分布式事务
              优点:交由数据库管理,简单有效
              缺点:性能代价高,特别是shard(分片)越来越多时
          方案二:由应用程序和数据库共同控制
               原理:将一个跨多个数据库的分布式事务分拆成多个仅处
                     于单个数据库上面的小事务,并通过应用程序来总控
                     各个小事务。
               优点:性能上有优势
               缺点:需要应用程序在事务控制上做灵活设计。如果使用  
                     了spring的事务管理,改动起来会面临一定的困难。
  2.跨节点Join的问题
       只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

  3.跨节点的count,order by,group by以及聚合函数问题

      这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。

  解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。

    

网友评论

登录后评论
0/500
评论
程序狗狐狸
+ 关注