精华内容
下载资源
问答
  • mysql分表分库技术实现
    万次阅读 多人点赞
    2019-11-05 10:29:15

    由于业务需要,需要对Mysql数据库进行分库分表,故而最近一直在整理分库分表的相关知识,现手上的工作也告一段落了,抽空将自己最近的学习结果转化为博文,分享给大家,本博文打算做成一个系列的,首先是分库分表的理论知识的了解,其次是基于Java编程语言的分库分表的框架的开发,最后是分库分表的编制。让大家不仅仅从理论上了解mysql的分库分表,通过代码来更深层次的了解,理论是如何落地到实践的。最后非常感谢《可伸缩服务架构 框架与中间件》这本书的作者么,本博文的代码实现是参考此书,然后结合当前系统平台框架开发而成。

    坚持我写作的一贯风格,我们先需要带着问题来了解mysql的分库分表

    • 什么是分库分表,为什么我们需要分库分表
    • 如何进行分库分表,有什么优缺点
    • 对于分库分表有哪些架构设计,对于后期的扩容扩展怎么样
    • 目前行业内流行的解决方案有哪些?各自有什么特点
    • 自己设计一个数据库分库分表的框架,如何设计,需要考虑哪些因素

    为什么需要分库分表

    随着我们的系统运行,存储在关系型数据库的数据量会越来越大,系统的访问的压力也会随之增大,如果一个库中的表数据超过了一定的数量,比如说mysql中的表数据达到千万级别,就需要考虑进行分库分表;

    其次随着表数据的不断增大,会发现,查询也随着变得缓慢,如果添加索引的话,会发现影响到了新增和删除的性能,如果我们将数据库分散到不同的表上,单表的索引大小就得到了控制,对索引以及表结构的变更会变得很方便和高效;

    当数据库实例的吞吐量达到性能的瓶颈时,我们需要扩展数据库实例,让每个数据库实例承担其中一部分数据库的请求,分解总体的大请求量的压力;

    在数据库进行扩容的时候对应用层的配置改变最少, 就需要在每个数据库实例中预留足够的数据库数量

    以上的情况我们都可以使用分库分表,那么什么是分库分表呢?

    简而言之就是数据拆分:将一个表结构分为多个表,或者将一个表数据分片后放入多个表,这些表可以放在同一个数据库里,也可以放到不同的数据库中,甚至可以放到不同的数据库实例中

    数据拆分的方式

    数据拆分有两种方式:

    • 垂直拆分: 根据业务的维度,将原本一个库中的表拆分多个表,每个库中表与原有的结构不同
    • 水平拆分: 根据分片算法,将一个库拆分成多个库,每个库依旧保留原有的结构

    在实际的开发过程中,通常是先进行维度拆分形成微服务结构,然后再进行水平拆分

    分库分表

    比如我们有一张表,随着业务的不断进行,mysql中表中数据量达到了10亿,若是将数据存放在一张表中,则性能一定不会太好,根据我们使用的经验,mysql数据库一张表的数据记录极限一般在5000万左右,所以我们需要对进行分片存储(水平拆分),按照5000万一个单位来拆分的话,需要切片数量20个,也就是20个数据库表

    如果将20个相同业务表存放在同一个数据库中,那么单个数据库实例的网卡I/O、内存、CPU和磁盘性能是有限的,随着数据库访问频率的增加,会导致单个数据库实例和数据库达到性能瓶颈,因此我们需要将20个表分到多个数据库和多个数据库实例中,具体的评估如下:
    【TODO 对数据库实例和数据库表的数量的评估】

    image

    如何进行分库分表

    分库分表是对数据库拆分的一种解决方案,根据实施切片逻辑的层次不同,我们将分库分表方案大致分为三大类:客户端分片、代理分片和支持事务的分布式数据库

    • 客户端分片

    所谓的客户端分片即在使用数据库的应用层直接操作分片逻辑,分片规则需要在同一个应用的多个节点间进行同步,每个应用层嵌入一个操作切片的逻辑实现。

    image

    在客户端分片,目前主要有以下三种方式:

    1. 在应用层直接实现

    这是一种非常通用的解决方案,直接在应用层读取分片规则,解析分片规则,根据分片规则实现切分的路由逻辑,从应用层直接决定每次操作应该使用哪个数据库实例中的对应的数据库

    这种解决方案虽然有一定的代码侵入,但是实现起来比较简单,但是切片的逻辑是自己开发的, 如果生产上遇到了问题,能快速定位解决;

    当然这种方式也存在缺点:代码的耦合度比较高,其次这种实现方式会让数据库保持的链接比较多,这要看应用服务的节点数量,需要提前进行容量上的评估

    1. 通过定制JDBC协议实现

    这种解决方案主要是为了解决1中解决方案中的代码耦合,通过定制JDBC协议来实现(主要是针对业务逻辑层提供与JDBC一致的接口),让分库分表在JDBC的内部实现

    目前当当网开源的框架:Sharding JDBC 就是使用这种解决方案来实现的

    1. 通过定制ORM框架实现

    目前ORM框架非常流行,流行的JPA、Mybatis和Hibernate都是优秀的ORM框架,通过定制ORM框架来实现分库分表方案,常见的有基于Mybatis的分库分表方案的解决;

        <select id="selectUser" parameterType="java.util.Map" resultType="User">
            select user_id as userId,user_name as userName
            from user_#{index}
            where user_id = #{userId}
        </select>
    
    • 代理分片

    代理分片就是在应用层和数据库层之间添加一个代理层,把分片的路由规则配置在代理层,代理层对外提供与JDBC兼容的接口给应用层,在业务实现之后,在代理层配置路由规则即可;

    image

    这种方案的优点:让应用层的开发人员专注于业务逻辑的实现,把分库分表的配置留给代理层处理
    同样的业务存在缺点:增加了代理层,这样的话对每个数据库操作都增加了一层网络传输,这对性能是有影响的,同时需要维护增加的代理层,也有了硬件成本,线上生产环境出现了问题,不能迅速定位,需要有一定的技术专家来维护

    我们常见的 Mycat就是基于此种解决方案来实现的

    • 支持事务的分布式数据库

    支持分布式事务的框架,目前有OceanBase、TiDB框架,这些框架将可伸缩特定和分布式事务的实现包装到了分布式数据库内部实现,对使用者透明,使用者不需要直接控制这些特性,但是对事务的支持不如关系型数据,适合大数据日志系统、统计系统、查询系统、社交网站等

    分库分表的架构设计

    上面我们介绍过数据拆分的两种方式:垂直拆分和水平拆分;

    拆分方式优点缺点
    垂直拆分1. 拆分后业务清晰,拆分规则明确
    2. 系统之间进行整合或扩展容易
    3. 按照成本、应用等级、应用的类型等将表放到不同的机器上,便于管理
    4.便于实现动静分离、冷热分离的数据库表的设计模式
    5. 数据维护简单
    1. 部分业务表无法进行关联、只能通过接口的方式来解决,提高了系统的复杂度
    2. 受每种业务不同的限制,存在单库性能瓶颈,对数据扩展和性能提升不友好
    3. 事务处理复杂
    水平拆分1. 单裤单表的数据保持一定的量级,有助于性能的提高
    2. 切分的表的结构相同,应用层改造较少,只需要增加路由规则即可
    3. 提高了系统的稳定性和负载能力
    1. 切分后数据是分散的,很难利用数据库的关联查询,跨库查询性能较差
    2. 拆分规则难以抽象
    3. 分片数据的一致性难以解决
    4. 数据扩容的难度和维护量极大

    综上所述,我们发现垂直拆分和水平拆分具有共同点:

    1. 存在分布式事务问题
    2. 存在跨节点join的问题
    3. 存在跨节点合并排序、分页的问题
    4. 存在多数据源管理的问题

    垂直拆分更偏向于业务拆分的过程,在技术上我们更倾向于水平切分的方案;

    常见的分片策略:

    • 按照哈希切片

    对数据库的某个字段进行来求哈希,再除以分片总数后取模,取模后相同的数据为一个分片,这样将数据分成多个分片的方法叫做哈希分片

    我们大多数在数据没有时效性的情况下使用哈希分片,就是数据不管是什么时候产生的,系统都需要处理或者查询;

    优点缺点
    数据切片比较均匀,数据压力分散的效果好数据分散后,对于查询需求需要进行聚合处理
    • 按照时间切片

    按照时间的范围将数据分布到不同的分片上,比如我们可以将交易数据按照与进行切片,或者按照季度进行切片,由交易数据的多少来决定按照什么样的时间周期来进行切片

    这种切片方式适合明显时间特点的数据,常见的就是订单历史查询

    分布式事务

    本博文不进行分布式事务的分析和实践,后期我会更新一系列的分布式事务的博文,一起探讨分布式事务的原理、解决方案和代码实践等,本博文简单介绍了分布式事务的解决方案;

    上面说到的,不管是垂直拆分还是水平拆分,都有一个共同的问题:分布式事务

    我们将单表的数据切片后存储在多个数据库甚至是多个数据库实例中,所以依靠数据库本身的事务机制不能满足需要,这时就需要用到分布式事务来解决了

    三种解决方案

    • 两阶段提交协议

    两阶段提交协议中的两阶段是:准备阶段和提交阶段,两个阶段都是由事务管理器(协调者)发起,事务管理器能最大限度的保证跨数据库操作的事务的原子性。

    具体的交互逻辑如下:

    image

    优点缺点
    是分布式系统环境下最严格的事务实现防范,
    保证了数据一致性和操作原子性
    1. 难以进行水平伸缩,因为在提交事务过程中,事务管理器需要和每个参与者进行准备和提交的操作协调
    2.每个参与者之间的协调需要时间,参与者一多的话,则锁定资源和消费资源之间的时间差就边长
    3. 两阶段提交协议是阻塞协议,在极端情况下不能快速响应的话,会造成阻塞问题
    • 最大努力保证模式

    这是一种非常通用的保证分布式一致性的模式,适合对一致性要求不是十分严格的但是对性能要求比较高的场景

    最大努力保证模式:在更新多个资源时,将多个资源的提交尽量延后到最后一刻进行处理,这样的话,如果业务流程出现问题,则所有的资源更新都可以回滚,事务仍然保持一致。

    最大努力保证模式在发生系统问题,比如网络问题等会出现问题,造成数据一致性的问题 ,这是就需要进行实时补偿,将已提交的事务进行回滚

    一般情况下,使用消息中间件来完成消费者之间的事务协调,客户端从消息中间件的队列中消费消息,更新数据库,此时会涉及到两个操作,一是从消息中间件消费消息,二是更新数据库,具体的操作步骤如下:

    1. 开启消息事务
    2. 接收消息
    3. 开启数据库事务
    4. 更新数据库
    5. 提交数据库事务
    6. 提交消息事务

    上述步骤最关键的地方在5和6,如果5成功了,但是6出现了问题,导致消息中间件认为消息没有被成功消费,既有的机制会重新再消费消息,就会出现消息重复消费,这是需要幂等处理来避免消息的重新消费

    其次我们还需要注意消息消费的顺序性问题,以及消费过程中是否调用远程接口等耗时操作

    优点缺点
    性能较高1. 数据一致性不能完美保证,只能是最大保证
    2. 可能出现消息重复消费(幂等处理)
    3. 数据库事务可能存在远程操作嵌套,互相影响
    • 事务补偿机制

    以上提到的两种解决方案:两阶段提交协议对系统的性能影响较大,最大努力保证模式会是多个分布式操作互相嵌套,有可能互相影响,那么我们采用事务补偿机制:

    事务补偿即在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链,则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态,也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理,建立跨资源的事务上下文.

    我们通过跨银行转账来说明:

    首先调用取款服务,完全调用成功并返回,数据已经持久化。然后调用异地的存款服务,如果也调用成功,则本身无任何问题。如果调用失败,则需要调用本地注册的逆向服务(本地存款服务),如果本地存款服务调用失败,则必须考虑重试,如果约定重试次数仍然不成功,则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件,由消息中间件接管后续操作。

    最后添加的重试机制是最大程度的确保补偿服务执行,保持数据的一致性,如果重试之后还是失败,则将操作保存在消息中间件中,等待后续处理,这样就更多了一重保障

    image

    分库分表引起的问题

    由于将完整的数据分成若干份,在以下的场景中会产生多种问题

    • 扩容与迁移

    在分库分表中,如果涉及的分片已经达到了承载数据的最大值,就需要对集群进行扩容,通常包括以下的步骤

    1. 按照新旧分片规则,对新旧数据库进行双写
    2. 将双写前按照旧分片规则写入的历史数据,根据新分片规则迁移写入新的数据库
    3. 将按照旧的分片规则查询改为按照新的分片规则查询
    4. 将双写数据库逻辑从代码中下线,只按照新的分片规则写入数据
    5. 删除按照旧分片规则写入的历史数据

    2步骤中迁移数据时,数据量非常大,通常会导致不一致,因此需要先迁移旧的数据,洗完后再迁移到新规则的新数据库下,再做全量对比,对比评估在迁移过程中是否有数据的更新,如果有的话就再清洗、迁移,最后以对比没有差距为准

    • 分库分表维度导致的查询问题

    进行了分库分表以后,如果查询的标准是分片的主键,则可以通过分片规则再次路由并查询,但是对于其他主键的查询、范围查询、关联查询、查询结果排序等,并不是按照分库分表维度查询的;

    这样的话,解决方案有以下三种:

    1. 在多个分片表中查询后合并数据集,这种方式的效率最低
    2. 冗余记录多份数据,方便查询, 缺点是需要额外维护一份数据,浪费资源
    3. 通过搜索引擎解决,但如果实时性要求很高,就需要实现实时搜索,可以利用大数据相关特性来解决
    • 跨库事务难以实现

    同时操作多个库,则会出现数据不一致的情况,此时可以引用分布式事务来解决

    • 同组数据跨库问题

    要尽量把同一组数据放到同一数据库服务器上,不但在某些场景下可以利用本地事务的强一致性,还可以是这组数据自治

    主流的解决方案

    目前针对mysql的分库分表,行业内主流的解决方案有:ShardingJDBC、Mycat

    Mycat代理分片框架

    Mycat是一款面向企业级应用的开源数据库中间件产品,他目前支持数据库集群,分布式事务与ACID,被普遍视为基于Mysql技术的集群分布式数据库解决方案

    Mycat支持多种分片规则:

    • 枚举法
    • 固定分片的hash算法
    • 范围约定
    • 求模法
    • 日期列分区法
    • 通配取模
    • ASCII码求模通配
    • 编程指定
    • 截取数据哈希解析
    • 一致性Hash

    具体的Mycat使用方法,以后应该会有一博文来整理,敬请期待啊~~~

    更多相关内容
  • MySql分表分库思路

    千次阅读 2021-01-19 07:17:31
    分库和垂直分表第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库1.2CPU瓶颈第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适...

    一.数据库瓶颈

    1.1IO瓶颈

    第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO -> 分库和垂直分表

    第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库

    1.2CPU瓶颈

    第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。

    第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水直分表。

    二.分表分库

    2.1水平分库

    8a27071f22befb95fee50946c7d64012.png   

    f5234f9a563b7485a093b9db95d18be4.png

    1. 以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

    2. 结果:

    每个库的结构都一样;

    每个库的数据都不一样,没有交集;

    所有库的并集是全量数据;

    3.场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

    4.分析:库多了,io和cpu的压力自然可以成倍缓解。

    2.2水平分表

    ef9e8c998df68248e9e71583d2416fcc.png

    1.概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。

    2.结果:

    每个表的结构都一样;

    每个表的数据都不一样,没有交集;

    所有表的并集是全量数据;

    3.场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

    4.分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。

    2.3垂直分库

    27df0e5e28b992b0c7d292c0e1dbb315.png

    1.概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。

    2.结果:

    每个库的结构都不一样;

    每个库的数据也不一样,没有交集;

    所有库的并集是全量数据;

    3.场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。

    4.分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

    2.3垂直分表

    90aa035969a51080d4b44378cdc49a00.png

    1.概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。

    2.结果:

    每个表的结构都不一样;

    每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据;

    所有表的并集是全量数据;

    3.场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。

    4.分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

    三.分表分库的工具

    sharding-sphere:jar,前身是sharding-jdbc;

    TDDL:jar,Taobao Distribute Data Layer;

    Mycat:中间件。

    本文只介绍Mycat工具。

    3.1Mycat简介

    Mycat的安装其实只要解压下载的目录就可以了,非常简单。安装完成后,目录如下:

    5935801d388445a2c2c6792a73559264.png

    Mycat的配置文件都在conf目录里面,这里介绍几个常用的文件:

    d7df857a15df5db5eccfe4fee9941f3e.png

    Mycat的架构其实很好理解,Mycat是代理,Mycat后面就是物理数据库。和Web服务器的Nginx类似。对于使用者来说,访问的都是Mycat,不会接触到后端的数据库。

    我们现在做一个主从、读写分离,简单分表的示例。结构如下图:

    49297d44005c3d6b453f183f1f7ccfce.png

    server.xml

    test

    lunch

    false

    97fc2c4fa69fcd6d00caffdb79738eb2.png

    schema.xml

    schema.xml是最主要的配置项,首先看我的配置文件。

    select user();

    select user();

    说明:

    e6332dbd614b7f219a26f45cb0c5179b.png

    5aecfcbcbc5404a5488a8622be63fef5.png

    75b6e53377f45c01dd34fcae7d1f0e9a.png

    数据库分表分库:

    配置如下:

    select user();

    select user();

    我在192.168.0.3、192.168.0.4均有数据库lunch。

    lunchmenu、restaurant、userlunch、users这些表都只写入节点dn1,也就是192.168.0.3这个服务,而dictionary写入了dn1、dn2两个节点,也就是192.168.0.3、192.168.0.4这两台服务器。分片的规则为:mod-long。

    主要关注rule属性,rule属性的内容来源于rule.xml这个文件,Mycat支持10种分表分库的规则,基本能满足你所需要的要求,这个必须赞一个,其他数据库中间件好像都没有这么多。

    table中的rule属性对应的就是rule.xml文件中tableRule的name,具体有哪些分表和分库的实现,建议还是看下文档。我这里选择的mod-long就是将数据平均拆分。因为我后端是两台物理库,所以rule.xml中mod-long对应的function count为2,见下面部分代码:

    id

    mod-long

    2

    数据库读写分离

    select user();

    3.2My的使用

    ##启动

    mycat start

    ##停止

    mycat stop

    ##重启

    mycat restart

    展开全文
  • php mysql分库分表实例

    2021-08-28 09:09:03
    php分库分表
  • MySQL 分库分表实现原理及演示案例,非常不错,可以看看
  • MySQL分库分表

    千次阅读 2022-03-14 08:37:02
    MySQL分库分表

    1.分库分表产生的背景

    采用单数据库存储存在以下的性能瓶颈:

    ①IO瓶颈:热点数据太多,数据库缓存不足,产生大量磁盘IO,效率较低。请求数据太多,带宽不够,网络IO瓶颈。

    ②CPU瓶颈:排序,分组,连接查询,聚合统计等SQL会消耗大量的CPU资源,请求数太多,CPU出现瓶颈。

    分库分表将数据分散存储,使得单一数据库/表的数据量变小来缓解单一数据库的性能问题。

    2.拆分策略:

    水平拆分:水平分表,水平分库;

    垂直拆分:垂直分表,垂直分库。

    垂直分库:以表为依据,根据业务将不同表拆分到不同库中。特点:①每个库的表结构都不一样;②每个库的数据也不一样;③所有库的并集是全量数据。下图为垂直分库案例。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

    垂直分表:以字段为依据,根据字段属性将不同字段拆分到不同表中。特点:①每个表的结构都不一样;②每个表的数据也不一样,一般通过一列(主键/外键)关联;③所有表的并集是全量数据。下图为垂直分表的案例,两张表以主键id关联。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16水平分库:以字段为依据,按照一定策略,将一个库的数据拆分到多个库中。特点:①每个库的表结构都一样;②每个库的数据都不一样;③所有库的并集是全量数据。下图为水平分库。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

    水平分表:以字段为依据,按照一定的策略,将一个表的数据拆分到多个表中。特点:①每个表的表结构都一样;②每个表的数据都不一样;③所有表的并集是全量数据。下图为水平分表。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

     3.分库分表的实现技术

    shardingJDBC:基于AOP原理,在应用程序对本地执行的SQL进行拦截,解析,改写,路由处理。需要自行编码配置实现,支持java语言,性能较高。

    MyCat:数据库分库分表中间件,不用调整代码即可实现分库分表,支持多种语言,性能不及shardingJDBC。

    4.MyCat

    MyCat是一个数据库中间件,使用MyCat也很简单,把我们之前连接数据库换成连接MyCat即可。

    6698af3262854497a052961c0d52d0ac.png

     mycat的核心概念:mycat中不存储数据,数据都是存储在节点主机中的,依照分片规则来决定存储在哪个节点主机;mycat只是一个逻辑结构,它是无感知的。watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

     5.mycat分片配置

    schema.xml涵盖了mycat的逻辑库,逻辑表,分片规则,分片节点及数据源的配置。主要包含三组标签:schema标签,datanode标签,datahost标签

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

     配置完schema.xml后,还要修改同级目录的server.xml文件,将schemas换成我们配置的schema;

    server.xml配置文件包含了mycat的系统配置信息,主要有两个重要标签:system,user

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

    rule.xml中定义所有拆分表的规则,在使用过程中可以灵活使用分片算法,或对同一个分片算法使用不同的参数,它让分片过程可配置化,主要保护局两类标签:tableRule,function。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YyX57-f,size_20,color_FFFFFF,t_70,g_se,x_16

     6.mycat启动

    mycat启动后,占用端口8066。 

    7.mycat分片

    垂直分库

    mycat分片情况下,涉及跨库查询(跨分片查询)会报错,因为mycat无法确定该SQL应该路由到哪个分片。

    解决方案:将涉及的表设置为全局表(在schema.xml中table标签加上type='global',dataNode为所有的节点),mycat对全局表任意节点进行DML时,所有节点都会同步进行

    水平分表

    水平分表的核心在于分片规则,只有水平分表才需要填写分片规则。

    8.常见的分片规则:

    范围分片:根据指定的字段及其配置的范围与数据节点的对应情况,来决定该数据属于哪一个分片。rule='auto-sharding-long';

    取模分片:根据指定的字段与节点数量进行求模运算,根据运算结果,来决定该数据属于哪一个分片。rule='mod-long';

     

    一致性hash分片:根据指定的字段,算出字段的hash值,根据运算结果,来决定该数据属于哪一个分片。rule='sharding-by-murmur';

     

    枚举分片:通过在配置文件中配置可能的枚举值,指定数据分布到不同数据节点上,本规则适用于按照省份,性别,状态拆分数据等业务。rule='sharding-by-intfile-enumstatus';

    超过枚举值的数据要指定一个节点存储。

     

    应用指定分片:运行阶段由应用自主决定路由到哪个分片,直接根据字符串(必须是数字)计算分片号。rule='sharding-by-substring';

     

    固定分片hash算法:该运算类似于十进制的求模运算。例如:取id的二进制低10位与1111111111进行位&运算。rule='sharding-by-long-hash';

    位&运算:同为1则为1,有一个0则为0。例如:
    1010101010&1111111111 = 1010101010

    特点:①如果是求模,连续的值分别分配到各个不同的分片,但是此算法会将连续的值可能分配到相同的分片,降低事务处理的难度;②可以均匀分配,也可以非均匀分配;③分片字段必须为数字类型

    字符串hash解析分片:截取字符串中的指定位置的字符串,进行hash算法,算出分片。rule='sharding-by-stringhash'; 

     按(天)日期分片:从开始时间开始,每10天(可以自行设置)为一个分片,到达结束时间后,会重复开始分片插入。rule='sharding-by-date'; 

    配置表的DataNode的分片,必须和分片规则数量一致,例如2022-01-01到2022-12-31,每10天一个分片,一共需要37个分片。因此,开始日期和结束日期一定要注意选择。

     按自然月分片:按照月份分片,每个自然月为一个分片。rule='sharding-by-month'; 

    配置表的DataNode的分片,必须和分片规则数量一致,例如2022-01-01到2022-12-31,一共需要12个分片。因此,开始日期和结束日期一定要注意选择。

     9.mycat的监控与管理

    9.1、mycat的原理

    每一个节点都只存储了一部分数据,因此,聚合处理、排序处理和分页处理等在各个节点处理是没有任何意义的,mycat会先将查询的结果合并然后再进行处理。

     9.2、mycat管理

    mycat默认开通2个端口,可以在server.xml中进行修改。8066数据访问端口和9066数据库管理端口。

     9.3、mycat图形化界面mycat-eye

    mycat-eye是对mycat-server提供监控服务,功能不局限于对mycat-server使用,通过JDBC连接对mycat,mysql监控,监控远程服务器(目前仅限于linux系统)的cpu、内存、网络、磁盘。

    mycat-eye运行过程中需要依赖zookeeper,因此需要先安装zookeeper。

     

    展开全文
  • Python+MySQL分表分库实战,适合对MySQL 分库分表感兴趣的读者。
  • 主要介绍了MyBatis实现Mysql数据库分库分表操作和总结,需要的朋友可以参考下
  • 需要进行数据的处理,采用的手段是分区、分片、分库分表。 二、分片(类似分库)  分片是把数据库横向扩展(Scale Out)到多个物理节点上的一种有效的方式,其主要目的是为突破单节点数据库服务器的 I/O 能力限制...
  • 六、分库分表总结 分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。 选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的...

    Python乱炖推荐搜索后浪

    动森玩家

    送书

    数据分析

    一、数据库瓶颈

    不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。

    1、IO瓶颈

    第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。

    第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。

    2、CPU瓶颈

    第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。

    第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表。

    二、分库分表

    1、水平分库

    972e57f1fbff8ab6171895d4a705cda2.png

    概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

    结果:

    每个库的结构都一样;

    每个库的数据都不一样,没有交集;

    所有库的并集是全量数据;

    场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

    分析:库多了,io和cpu的压力自然可以成倍缓解。

    2、水平分表

    24be0dd1681c322aee42d0b81410724b.png

    概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。

    结果:

    每个表的结构都一样;

    每个表的数据都不一样,没有交集;

    所有表的并集是全量数据;

    场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

    分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。

    3、垂直分库

    563774d6332fa4f85027ad72635340e6.png

    概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。

    结果:

    每个库的结构都不一样;

    每个库的数据也不一样,没有交集;

    所有库的并集是全量数据;

    场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。

    分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

    4、垂直分表

    28a62d12c5d32bd53cf59f126b0736b3.png

    概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。

    结果:

    每个表的结构都不一样;

    每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据;

    所有表的并集是全量数据;

    场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。

    分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

    三、分库分表工具

    sharding-sphere:jar,前身是sharding-jdbc;

    TDDL:jar,Taobao Distribute Data Layer;

    Mycat:中间件。

    注:工具的利弊,请自行调研,官网和社区优先。

    四、分库分表步骤

    根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。

    五、分库分表问题

    1、非partition key的查询问题

    基于水平分库分表,拆分策略为常用的hash法。

    端上除了partition key只有一个非partition key作为条件查询

    映射法

    cbb0fee2ea5d6b1bac390694827d12dc.png

    基因法

    5d1d9388ba78c1aa6ccfc6e74976b8cd.png

    注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,23=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。

    端上除了partition key不止一个非partition key作为条件查询

    映射法

    ea04b48415208f0c49910be369aef05a.png

    冗余法

    18d30624cbd0808af67495e43edfaeea.png

    注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢?

    后台除了partition key还有各种非partition key组合条件查询

    NoSQL法

    ab8bb73af6185673593b043a2c5842a9.png

    冗余法

    6997e211ea687fb4e9cd24d2439fb3ee.png

    2、非partition key跨库跨表分页查询问题

    基于水平分库分表,拆分策略为常用的hash法。

    注:用NoSQL法解决(ES等)。

    3、扩容问题

    基于水平分库分表,拆分策略为常用的hash法。

    水平扩容库(升级从库法)

    110eeaf83c9394d25889c0c3278ae938.png

    注:扩容是成倍的。

    水平扩容表(双写迁移法)

    998c7b1bb38929e02cb57ee18277ac65.png

    第一步:(同步双写)修改应用配置和代码,加上双写,部署;

    第二步:(同步双写)将老库中的老数据复制到新库中;

    第三步:(同步双写)以老库为准校对新库中的老数据;

    第四步:(同步双写)修改应用配置和代码,去掉双写,部署;

    注:双写是通用方案。

    六、分库分表总结

    分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。

    选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的查询。

    只要能满足需求,拆分规则越简单越好。

    七、分库分表示例

    来自:cnblogs.com/littlecharacter/p/9342129.html

    以上,便是今天的内容,希望大家喜欢,欢迎「转发」或者点击「在看」支持,谢谢各位。

    “扫一扫,关注我吧”

    展开全文
  • 内容详细,亲测可用,包含图文介绍
  • Node.js 的 MySQL 分表分库数据访问中间件,实现MySQL数据的分布式集群储存管理。在处理海量数据、高并发访问时,获得更加优越的性能及横向扩展能力。它包含以下主要特性: 可伸缩、高扩展的架构 ...
  • 本文讲的是mysql大数据分库分表 php解决方案。 mysql分库分表方案、mysql 分库方案、php实现mysql分库分表mysql高并发解决方案。
  • 为大家讲述一下在mysql在什么到时候需要进行分表分库,以及现实的设计方式。
  • Mysql分库分表

    2022-04-08 22:55:31
    文章目录Mysql分库分表一、Mysql分表分库1.垂直拆分2.水平拆分二、如何分表分库1.常用数据库中间件2.分表分库策略三.Shadingjdbc整合1.Maven依赖2.相关配置a.整合分表b.整合分表四、分表分库语句查询原理1.查询语句...
  • 一、先说一下为什么要分表: 当一张的数据达到几百万时,你...数据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作
  • 主要介绍了MySQL数据库优化之分表分库操作,结合实例形式详细分析了mysql数据库分表分库垂直拆分、水平拆分相关原理以及应用案例,需要的朋友可以参考下
  • 本文主要给大家介绍Mysql数据库分库分表方式(常用),涉及到mysql数据库相关知识,对mysql数据库分库分表相关知识感兴趣的朋友一起学习吧
  • mysql分库备份和分表备份 分库备份:将 mysql 数据库中的用户数据库备份,备份的数据库文件以时间命名 分库分表备份:备份每个数据库的表,同一个库中的表,放在对应数据库名字命名的目录下
  • 前期在于重点解决 MySQL 的单机性能和容量无法线性和灵活扩展的问题,最终选择了 Mycat,在调研阶段,对以下技术特性进行了重点考虑: 协议兼容 MySQL 支持 SQL 92标准 可在线扩展 支持读写分离,支持Mysql双主多从...
  • 分库分表 基本分库分表: 1:分库分表 2:分库表冗余 3:分区表 分布式事务 1:XA分布式事务 2:TCC分布式事务 3:消息分布式事务 Mycat分片规则 Mycat读写分离 Mycat故障切换 Mycat+Percona+Haproxy+keepalived Zookeeper...
  • mysql索引分析开始,介绍如何建立索引,什么情况需要建立索引,以及查询截取分析,mysql 的锁机制,主从复制,分表分库mysql高级部分知识结构
  • Mysql 分库分表

    千次阅读 2021-11-14 22:30:28
    使用分库分表时,主要有垂直拆分和水平拆分两种拆分模式,都属于物理空间的拆分。 分库分表方案:只分库、只分表分库分表。 垂直拆分:由于表数量多导致的单个库大。将表拆分到多个库中。 水平拆分:由于表...
  • MYSQL分库分表

    千次阅读 2022-03-28 00:36:37
    分库分表 关系型数据库本身⽐较容易成为系统瓶颈,单机存储容量、连接数、处理能⼒都有限。当单表的数据量 达到2000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严 重。此时就要...
  • MySQL分库分表技术

    2013-12-11 19:52:40
    这个PPT由浅入深,从很少的用户到千万级别的用户,告诉你为什么要使用分库分表,包括垂直和水平切分,偏入门的理论,代码基本无
  • 天继续给大家介绍MySQL相关知识,本文主要内容是MySQL数据库的分库分表思路。 一、分库分表基本原理 二、分库分表存在的问题

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,913
精华内容 27,565
关键字:

mysql分表分库技术实现

mysql 订阅