分库分表的几种常见形式以及可能遇到的难题

一般分表分库是按部就班的过程,若是一开始就分表分库设计,除非有大量的开发设计时间;要否则都显得过分设计;数据库

通常是在数据库读写出现瓶颈是才考虑分表分库,若是数据表设计的合理,但张表达到一千万的数据,查询也不会出现性能问题;分布式

那么若是实在要分表分库,应该怎么设计,网上也提供了各类资料;我总结一些我看过的性能

1、垂直分表spa

也就是大表分小表,这个最好是在表设计时就考虑到;把经常使用的字段和管理的不经常使用字段分别放在不一样的表,设计成主表和额外信息表;设计

2、水平分表接口

也称为横向分表,就是把表中不一样数据行按照必定的规律分布到不一样的数据库表中(依然是同一个数据库),如此下降单张表的数据量,事务

能提升查询性能;最多见的方式就是经过主键或者时间等字段进行hash和取模后拆分,为的是避免热点数据;这是这种方式也同时未能资源

解决同一个库IO瓶颈问题;开发

3、垂直分库get

也就是把不一样的业务数据表,分在不一样的数据库中;这种方式有利于系统的维护和扩展。但这种方式也会带来更大开发难度,若是把不一样

数据库放在不一样机器上,那么会带来没法跨库join、分布式事务等问题;

四,水平分库分表

其实意思跟水平分表差很少,只是把水平分的表再分到不一样的库中;

解决的问题:单机的IO压力,链接数;

带来的问题:投入的硬件资源多,技术更加复杂(如分片查询问题,分布试事务等),如下分析这些难题的解决办法;

分片查询问题:

    一、join查询

        1)字段冗余;

        2)若是是字典表,能够每一个库中都放一份相同的表;

    二、关联查询

        一、系统组装;不一样的模块提供查询接口,在代码层本身把查询数据组装;

        二、报表查询的话选择其余技术实现,不如OLAP和OLTP;

        三、丢给spark进行处理;

参考:分库分表的几种常见形式以及可能遇到的难题

相关文章
相关标签/搜索