分库分表知识必备

亿级数据量性能优化必备之分库分表
https://zhuanlan.zhihu.com/p/93724977
1.什么时候分库分表
   当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分
2.分库分表,到底怎么分。 数据切分(Sharding)
   数据切分就是将数据分散存储到多个数据库中,使得单一数据库中的数据量变小,同时扩充主机数量来缓解单一数据库的性能问题
   数据切分根据其切分类型,可以分为两种方式:垂直(纵向)切分和水平(横向)切分  
   垂直切分常见有垂直分库和垂直分表两种。
      垂直切分— 垂直分库。根据业务耦合性,将关联度低的不同表存储在不同的数据库。(隐患:分布式事务处理复杂,依然存在单表数据量过大的问题)
         |__垂直分表。某个表字段较多,把字段拆开散到多个表中.(隐患:部分表无法join,只能通过接口聚合方式解决,提升了开发的复杂度)

      水平切分.将同一个表按不同的条件分散到多个数据库或多个表中,每个表中只包含一部分数据
              (隐患:跨分片的事务一致性难以保证,跨库的join关联查询性能较差)
      —库内分表。只解决了单一表数据量过大的问题。还是竞争同一个物理机的CPU、内存、网络IO
      |_分库分表。
     常用的切分规则:
          —根据数值范围。按照时间区间或ID区间来切分。按日期将不同月甚至是日的数据分散到不同的库中
             某些系统中使用的"冷热数据分离",将一些使用较少的历史数据迁移到其他库中,业务功能上只提供热点数据的查询,也是类似的实践。
      |_根据数值取模。一般采用hash取模mod的切分方式
             例如:将 Customer 表根据 cusno 字段切分到4个库中,余数为0的放到第一个库,余数为1的放到第二个库,以此类推。
              这样同一个用户的数据会分散到同一个库中,如果查询条件带有cusno字段,则可明确定位到相应库去查询。
             优点:分布均匀,不容易出现热点和并发访问的瓶颈
             缺点:扩容时,需要迁移旧的数据。 还有跨分片查询时如果没有sharding key(上面例子的cusno字段)会更复杂。需要查多个库再合并。

3.分库分表导致复杂性增加,带来的问题与解决方案
   a.事务一致性问题.跨库和跨分片事务都是分布式事务,
      解决方法1:一般可使用"XA协议"和"两阶段提交"处理。
      复杂性增加的原因:分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点,推后了提交事务的时间点,
        延长了事务的执行时间。导致事务在访问共享资源时发生冲突或死锁的概率增高。
        随着数据库节点的增多,这种趋势会越来越严重,从而成为系统在数据库层面上水平扩展的枷锁。
     解决方法2:最终一致性。适用场景:对于那些性能要求很高,但对一致性要求不高的系统,往往不苛求系统的实时一致性,
             只要在允许的时间段内达到最终一致性即可,可采用事务补偿的方式。
         常见的实现方法有:对数据进行对账检查,基于日志进行对比,定期同标准数据来源进行同步等等。事务补偿还要结合业务系统来考虑。
   b.跨节点关联查询join问题
     解决方法1:全局表,即数据字典表,是系统中所有模块都可能依赖的一些表。在每个数据库中都保存一份。内容很少变动,不用担心一致性
     解决方法2:字段冗余。一种典型的反范式设计,利用空间换时间,为了性能而避免join查询。
              买家修改了userName后,是否需要在历史订单中同步更新呢?这也要结合实际业务场景进行考虑。
     解决方法3:数据组装。系统分两次查询,第一次查询的结果集中找出关联数据id,然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
     解决方法4:ER分片,先确定表之间的关联关系,将有关联关系的表数据放在1个库里面。来避免跨分片join问题
   c.跨节点分页、排序、函数问题
      跨节点多库进行查询时,会出现limit分页、order by排序等问题。
      分页需要按照指定字段进行排序,当排序字段就是分片字段时,通过分片规则就比较容易定位到指定的分片;当排序字段非分片字段时,就变得比较复杂了。
      需要先在不同的分片节点中将数据进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序,最终返回给用户。
   d、全局主键避重问题
      问题的背景原因:由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地,
           某个分区数据库自生成的ID无法保证全局唯一。因此需要单独设计全局主键,以避免跨库主键重复问题。
       有一些常见的主键生成策略:UUID  + 结合数据库维护主键ID表
   e.数据迁移、扩容问题.历史数据要按指定的分片规则再将数据写入到各个分片节点中。
      此外还需要根据当前的数据量和QPS,以及业务发展的速度,进行容量规划,推算出大概需要多少分片(一般建议单个分片上的单表数据量不超过1000W)

4. 支持分库分表的中间件
sharding-jdbc(当当)
TSharding(蘑菇街)
Atlas(奇虎360)
Cobar(阿里巴巴)
MyCAT(基于Cobar)
Oceanus(58同城)
Vitess(谷歌)
在数据量很大的情况下,还可以使用ES搜索引擎或Hive来满足后台复杂的查询方式。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值