MySQL 分库分表的项目实践

目录
  • 一、为什么要分库分表
  • 二、库表太大产生的问题
  • 三、垂直拆分
  • 1. 垂直分库
    • 2. 垂直分表
  • 四、水平分库分表

一、为什么要分库分表

数据库架构演变

刚开始多数项目用单机数据库就够了,随着服务器流量越来越大,面对的请求也越来越多,我们做了数据库读写分离, 使用多个从库副本(Slave)负责读,使用主库(Master)负责写,master和slave通过主从复制实现数据同步更新,保持数据一致。slave 从库可以水平扩展,所以更多的读请求不成问题

但是当用户量级上升,写请求越来越多,怎么保证数据库的负载足够?增加一个Master是不能解决问题的, 因为数据要保存一致性,写操作需要2个master之间同步,相当于是重复了,而且架构设计更加复杂

这时需要用到分库分表(sharding),把库和表存放在不同的MySQL Server上,每台服务器可以均衡写请求的次数

二、库表太大产生的问题

  • 单库太大:单库处理能力有限、所在服务器上的磁盘空间不足、遇到IO瓶颈,需要把单库切分成更多更小的库
  • 单表太大:CURD效率都很低、数据量太大导致索引文件过大,磁盘IO加载索引花费时间,导致查询超时。所以只用索引还是不行的,需要把单表切分成多个数据集更小的表。MyCat提供的分表算法都在rule.xml,可以根据不同的分表算法进行拆分,比如根据时间拆分、一致性哈希、直接用主键对分表的个数取模等

拆分策略

单个库太大,先考虑是表多还是数据多:

  • 如果因为表多而造成数据过多,则使用垂直拆分,即根据业务拆分成不同的库
  • 如果因为单张表的数据量太大,则使用水平拆分,即把表的数据按照某种规则(rule.xml定义的分表算法)拆分成多张表

分库分表的原则应该是先考虑垂直拆分,再考虑水平拆分

三、垂直拆分

分库分表和读写分离可以共同进行

1. 垂直分库

server.xml

<user name="root">
<property name="password">123456</property>
<property name="schemas">USERDB1,USERDB2</property>
</user>

配置了USERDB1、USERDB2这两个逻辑库

schema.xml

<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
	<!-- 逻辑数据库 -->
	<schema name="USERDB1" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1" /> <!-- 两个逻辑库对应两个不同的数据节点 -->
	<schema name="USERDB2" checkSQLschema="false" sqlMaxLimit="100"dataNode="dn2" />
	<!-- 存储节点 -->
	<dataNode name="dn1" dataHost="node1" database="mytest1" />  <!-- 两个数据节点对应两个不同的物理机器 -->
	<dataNode name="dn2" dataHost="node2" database="mytest2" />  <!-- USERDB1对应mytest1,USERDB2对应mytest2 -->
	<!-- 数据库主机 -->
	<dataHost name="node1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native">
		<heartbeat>select user()</heartbeat>
		<writeHost host="192.168.131.129" url="192.168.131.129:3306" user="root" password="123456" />
	</dataHost>

	<dataHost name="node2" maxCon="1000" minCon="10" balance="0"writeType="0" dbType="mysql" dbDriver="native">
		<heartbeat>select user()</heartbeat>
		<writeHost host="192.168.0.6" url="192.168.0.6:3306" user="root" password="123456" />
	</dataHost>
</mycat:schema>

两个逻辑库对应两个不同的数据节点,两个数据节点对应两个不同的物理机器

mytest1和mytest2分成了不同机器上的不同的库,各包含一部分表,它们原来是合在一块的,在一台机器上,现在做了垂直的拆分。
客户端就需要去连接不同的逻辑库了,根据业务操作不同的逻辑库

然后配置了两个写库,两台机器把库平分了,分担了原来单机的压力。分库伴随着分表,从业务上对表拆分

2. 垂直分表

垂直分表,基于列字段进行。一般是针对几百列的这种大表,也避免查询时,数据量太大造成的“跨页”问题。

一般是表中的字段较多,将不常用的, 数据较大,长度较长(比如text类型字段)的拆分到扩展表。访问频率较高的字段单独放在一张表

四、水平分库分表

针对数据量巨大的单张表(比如订单表),按照某种规则(RANGE、HASH取模等),切分到多张表里面去。 但是这些表还是在同一个库中,所以库级别的数据库操作还是有IO瓶颈,不建议采用

将单张表的数据切分到多个服务器上去,每个服务器具有一部分库与表,只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力,突破IO、连接数、硬件资源等的瓶颈

分库分表可以和主从复制同时进行,但不基于主从复制;读写分离才基于主从复制

server.xml

<user name="root">
	<property name="password">123456</property>
	<property name="schemas">USERDB</property>
</user>

schema.xml

<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
	<!-- 逻辑数据库 -->
	<schema name="USERDB" checkSQLschema="false" sqlMaxLimit="100">
		<table name="user" dataNode="dn1" /> <!-- 这里的user和student都是实际存在的物理表名 -->
		<table name="student" primaryKey="id" autoIncrement="true" dataNode="dn1,dn2" rule="mod-long"/>
	</schema>
	<!-- 存储节点 -->
	<dataNode name="dn1" dataHost="node1" database="mytest1" />
	<dataNode name="dn2" dataHost="node2" database="mytest2" />
	<!-- 数据库主机 -->
	<dataHost name="node1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native">
		<heartbeat>select user()</heartbeat>
		<writeHost host="192.168.131.129" url="192.168.131.129:3306" user="root" password="123456" />
	</dataHost>
	<dataHost name="node2" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native">
		<heartbeat>select user()</heartbeat>
		<writeHost host="192.168.0.6" url="192.168.0.6:3306" user="root" password="123456" />
	</dataHost>
</mycat:schema>

user表示一个普通的表,直接放在数据节点dn1上,放在一台机器上,这张表不用进行拆分

student表的primaryKey是id,根据id拆分,放在dn1和dn2上,最终这个表要分在两台机器上,在物理上分开了,但是在逻辑上还是一个,往哪张表里增加,在2台机器上查询然后如何合并这些操作都是由mycat完成的

拆分的规则是取模(mod - long),每次插入用id模上存在的机器数(2)

此外还需要在rule.xml中配置以下拆分算法

找到算法mod-long,因为我们将逻辑表student分开映射到两台主机上,所以修改数据节点的数量为2

2. 测试水平分表

Linux主机

Windows主机

登录到mycat的8066端口

使用MyCat给user表插入两条数据

由于schema.xml配置文件中,逻辑表user只在Linux主机的mytest1库中存在,mycat操作的逻辑表user会影响Linux主机上的物理表,而不会影响Windows主机上的表。我们分别查看一下Linux和Windows主机的user表:

我们再通过MyCat给student表插入两条数据

我们知道schema.xml配置文件中,逻辑表student对应两台主机上的两个库mytest1、mytest2中的两张表,所以对逻辑表插入的两条数据,会实际影响到两张物理表(用id%机器数,决定插入到哪张物理表)。我们分别查看一下Linux和Windows主机的student表:

再通过MyCat插入id=3和id=4的数据,应该插入不同主机上的不同物理表

这就相当于把student表进行水平拆分了

通过MyCat查询的时候只需要正常输入就行,我们配置的是表拆分后放在这2个数据节点上,MyCat会根据配置在两个库上查询并进行数据合并

到此这篇关于MySQL 分库分表的项目实践的文章就介绍到这了,更多相关MySQL 分库分表内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • MySQL常用分库分表方案汇总

    目录 一.数据库瓶颈 二.分库分表 2.水平分表 3.垂直分库 4.垂直分表 三.分库分表工具 四.分库分表步骤 五.分库分表问题 1.非partition key的查询问题 2.非partition key跨库跨表分页查询问题 3.扩容问题 六.分库分表总结 一.数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值.在业务Service来看就是,可用数据库连接少甚至无连接可用.接下来就可以想象了吧(并发量.吞吐量.崩溃).

  • MySQL 分表分库怎么进行数据切分

    关系型数据库本身比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限.当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库.优化索引,做很多操作时性能仍下降严重.此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间. 数据库分布式核心内容无非就是数据切分(Sharding)以及切分后对数据的定位.整合.数据切分就是将数据分散存储到多个数据库中,使得单一数据库中的数据量变小,通过扩充主机的数量缓解单一数据库的性能问题,从而达到提升数据库操作性能的目

  • MySql分表、分库、分片和分区知识深入详解

    一.前言 数据库的数据量达到一定程度之后,为避免带来系统性能上的瓶颈.需要进行数据的处理,采用的手段是分区.分片.分库.分表. 二.分片(类似分库) 分片是把数据库横向扩展(Scale Out)到多个物理节点上的一种有效的方式,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题.Shard这个词的意思是"碎片".如果将一个数据库当作一块大玻璃,将这块玻璃打碎,那么每一小块都称为数据库的碎片(DatabaseShard).将整个数据库打碎的过程就叫做分片,可以

  • MySQL分库分表详情

    一.业务场景介绍 假设目前有一个电商系统使用的是MySQL,要设计大数据量存储.高并发.高性能可扩展的方案,数据库中有用户表.用户会非常多,并且要实现高扩展性,你会怎么去设计? OK咱们先看传统的分库分表方式 当然还有些小伙伴知道按照省份/地区或一定的业务关系进行数据库拆分 OK,问题来了,如何保证合理的让数据存储在不同的库不同的表里呢?让库减少并发压力?应该怎么去制定分库分表的规则?不用急,这不就来了 二.水平分库分表方法 1.RANGE 第一种方法们可以指定一个数据范围来进行分表,例如从1~

  • MYSQL性能优化分享(分库分表)

    1.分库分表 很明显,一个主表(也就是很重要的表,例如用户表)无限制的增长势必严重影响性能,分库与分表是一个很不错的解决途径,也就是性能优化途径,现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢,同事的做法是将其散列到100个表中,分别从members0到members99,然后根据mid分发记录到这些表中,牛逼的代码大概是这样子: 复制代码 代码如下: <?php for($i=0;$i< 100; $i++ ){ //echo "CREATE TA

  • Mysql数据库分库和分表方式(常用)

    本文主要给大家介绍Mysql数据库分库和分表方式(常用),涉及到mysql数据库相关知识,对mysql数据库分库分表相关知识感兴趣的朋友一起学习吧 1 分库 1.1 按照功能分库 按照功能进行分库.常见的分成6大库: 1 用户类库:用于保存了用户的相关信息.例如:db_user,db_system,db_company等. 2 业务类库:用于保存主要业务的信息.比如主要业务是笑话,用这个库保存笑话业务.例如:db_joke,db_temp_joke等. 3 内存类库:主要用Mysql的内存引擎.

  • mysql分表分库的应用场景和设计方式

    很多朋友在论坛和留言区域问mysql在什么情况下才需要进行分库分表,以及采用何种设计方式才是最优的选择,根据这些问题,小编为大家整理了关于MySQL分库分表的应用场景和最优的设计方式举例. 一. 分表 场景:对于大型的互联网应用来说,数据库单表的记录行数可能达到千万级甚至是亿级,并且数据库面临着极高的并发访问.采用Master-Slave复制模式的MySQL架构, 只能够对数据库的读进行扩展,而对数据库的写入操作还是集中在Master上,并且单个Master挂载的Slave也不可能无限制多,Sl

  • MySQL分库分表总结讲解

    项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多.以至于查询变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈. 当出现这种情况时,我们可以考虑分库分表,即将单个数据库或表进行拆分,拆分成多个库和多个数据表,然后用户访问的时候,根据一定的算法与逻辑,让用户访问不同的库.不同的表,这样数据分散到多个数据表中,减少了单个数据表的访问压力.提升了数据库访问性能. 下面是对项目中分库分表的一些总结: 单库单表 单库单表是最常见的数据库设计,例如,有一张用户(use

  • MYSQL数据库数据拆分之分库分表总结

    数据存储演进思路一:单库单表 单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到. 数据存储演进思路二:单库多表 随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能.如果使用mysql, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能等待. 可以通过某种方式将user进行水平的切分,产生两个表结构完全一样的

  • MySQL分库分表与分区的入门指南

    前言 关系型数据库比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限,当数据量和并发量起来之后,就必须对数据库进行切分了. 数据切分(sharding)的手段就是分库分表.分库分表有两方面,可能是光分库不分表,也可能是光分表不分库. 数据库分布式的核心内容无非就是数据切分,以及切分后对数据的定位.整合. 为什么要分库分表 分表 单表数据量太大时,会严重影响sql执行的性能.一般单表到达几百万的时候,性能就会相对差一些了,这时就得分表了. 分表就是把一个表的数据放到多个表中,然后查询的时候

随机推荐