1 基本思想之什么是分库分表?
从字面上简单理解,就是把原本存储于一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表?
数
据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据 *** 作,增
删改查的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源(CPU、磁盘、内存、IO等)是有限的,最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
31
何谓垂直切分,即将表按照功能模块、关系密切程度划分出来,部署到不同的库上。例如,我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等,分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
32
何谓水平切分,当一个表中的数据量过大时,我们可以把该表的数据按照某种规则,例如userID散列,进行划分,然后存储到多个结构相同的表,和不同的库
上。例如,我们的userDB中的用户数据表中,每一个表的数据量都很大,就可以把userDB切分为结构相同的多个userDB:part0DB、
part1DB等,再将userDB上的用户数据表userTable,切分为很多userTable:userTable0、userTable1等,
然后将这些表按照一定的规则存储到多个userDB上。
33 应该使用哪一种方式来实施数据库分库分表,这要看数据库中数据量的瓶颈所在,并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、低耦合,那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多,但单表的数据量很大、或数据热度很高,这种情况之下就应该选择水平切分,水平切分比垂直切分要复杂一些,它将原本逻辑上属于一体
的数据进行了物理分割,除了在分割时要对分割的粒度做好评估,考虑数据平均和负载平均,后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中,往往是这两种情况兼而有之,这就需要做出权衡,甚至既需要垂直切分,又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分,我们首先对数据库进行垂直切分,然后,再针对一部分表,通常是用户数据表,进行水平切分。
4 分库分表存在的问题。
41 事务问题。
在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
42 跨库跨表的join问题。
在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,这时,表的关联 *** 作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
43 额外的数据管理负担和数据运算压力。
额
外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算,例如,对于
一个记录用户成绩的用户数据表userTable,业务要求查出成绩最好的100位,在进行分表之前,只需一个order
by语句就可以搞定,但是在进行分表之后,将需要n个order
by语句,分别查出每一个分表的前100名用户数据,然后再对这些数据进行合并计算,才能得出结果。
表间关系其实和数据库本身无关,是属于业务概念。
举个例子:
客户信息表,和客户绑定邮箱。
这个应该就是属于主表和子表的概念。
一般来说,表与表之间的关系,基本就是一对一,一对多,多对多。
比如上面的客户信息表,和客户绑定邮箱。
如果一个客户只能绑定一个邮箱,那就是一对一了。
如果改成客户信息表,和客户绑定信息,
一个客户可以绑定一个邮箱,一个电话号码,一个qq等等。那就是一对多的关系。
至于多对多,换个例子。
一个班级有活动小组,每个活动小组包含多名同学,一个同学也可以参加多个小组。
那么活动小组成员表,和班级成员表应该就是多对多的关系。
这里面一般像一对一和一对多的关系可以有约束----外键。
Mysql数据库3种存储(MyISAM、MEMORY、InnoDB)引擎区别:
1、Myisam是Mysql的默认存储引擎,当create创建新表时,未指定新表的存储引擎时,默认使用Myisam。MEMORY、InnoDB不是默认存储引擎。
2、InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比Myisam的存储引擎,InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
Mysql数据库3种存储(MyISAM、MEMORY、InnoDB)区别对比:
1、MyISAM
它不支持事务,也不支持外键,尤其是访问速度快,对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
数据文件和索引文件可以放置在不同的目录,平均分配IO,获取更快的速度。要指定数据文件和索引文件的路径,需要在创建表的时候通过DATA DIRECTORY和INDEX DIRECTORY语句指定,文件路径需要使用绝对路径。
2、MEMORY
memory使用存在内存中的内容来创建表。每个MEMORY表实际对应一个磁盘文件,格式是frm。MEMORY类型的表访问非常快,因为它到数据是放在内存中的,并且默认使用HASH索引,但是一旦服务器关闭,表中的数据就会丢失,但表还会继续存在。
默认情况下,memory数据表使用散列索引,利用这种索引进行“相等比较”非常快,但是对“范围比较”的速度就慢多了。因此,散列索引值适合使用在"="和"<=>"的 *** 作符中,不适合使用在"<"或">" *** 作符中,也同样不适合用在order by字句里。如果确实要使用"<"或">"或betwen *** 作符,可以使用btree索引来加快速度。
存储在MEMORY数据表里的数据行使用的是长度不变的格式,因此加快处理速度,这意味着不能使用BLOB和TEXT这样的长度可变的数据类型。VARCHAR是一种长度可变的类型,但因为它在MySQL内部当作长度固定不变的CHAR类型,所以可以使用。
3、InnoDB
InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎,InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
(1)自动增长列:
InnoDB表的自动增长列可以手工插入,但是插入的如果是空或0,则实际插入到则是自动增长后到值。可以通过"ALTER TABLEAUTO_INCREMENT=n;"语句强制设置自动增长值的起始值,默认为1,但是该强制到默认值是保存在内存中,数据库重启后该值将会丢失。
可以使用LAST_INSERT_ID()查询当前线程最后插入记录使用的值。如果一次插入多条记录,那么返回的是第一条记录使用的自动增长值。对于InnoDB表,自动增长列必须是索引。如果是组合索引,也必须是组合索引的第一列,但是对于MyISAM表,自动增长列可以是组合索引的其他列,这样插入记录后,自动增长列是按照组合索引到前面几列排序后递增的。
(2)外键约束:
MySQL支持外键的存储引擎只有InnoDB,在创建外键的时候,父表必须有对应的索引,子表在创建外键的时候也会自动创建对应的索引。
◆关系模型概述
◆关系数据结构
◆关系的完整性
◆关系代数
◆关系演算
关系数据库系统:是支持关系模型的数据库系统
◣关系模型的组成
1关系数据结构
单一的数据结构----关系
现实世界的实体以及实体间的各种联系均用关系来表示
数据的逻辑结构----二维表
从用户角度,关系模型中数据的逻辑结构是一张二维表。
2关系 *** 作集合
1)常用的关系 *** 作
◇查询:选择、投影、连接、除、并、交、差
◇数据更新:插入、删除、修改
查询的表达能力是其中最主要的部分
2)关系 *** 作的特点
集合 *** 作方式,即 *** 作的对象和结果都是集合。
(非关系数据模型的数据 *** 作方式:一次一记录文件系统的数据 *** 作方式)
3)关系数据语言的种类
◇关系代数语言
用对关系的运算来表达查询要求
典型代表:ISBL
◇关系演算语言:用谓词来表达查询要求元组关系演算语言
谓词变元的基本对象是元组变量
典型代表:APLHA, QUEL
◇域关系演算语言
谓词变元的基本对象是域变量
典型代表:QBE
◇具有关系代数和关系演算双重特点的语言
典型代表:SQL
4)关系数据语言的特点
◇关系语言是一种高度非过程化的语言
a存取路径的选择由DBMS的优化机制来完成
b用户不必用循环结构就可以完成数据 *** 作
◇能够嵌入高级语言中使用
◇关系代数、元组关系演算和域关系演算三种语言在表达能力上完全等价
3关系完整性约束
1)实体完整性
通常由关系系统自动支持
2)参照完整性
早期系统不支持,目前大型系统能自动支持
3)用户定义的完整性
反映应用领域需要遵循的约束条件,体现了具体领域中的语义约束
用户定义后由系统支持
◣关系数据结构
关系模型建立在集合代数的基础上
关系数据结构的基本概念
1关系
1)域(Domain)
域是一组具有相同数据类型的值的集合。
例:整数,实数,介于某个取值范围的整数,长度指定长度的字符串集合,{‘男’,‘女’},介于某个取值范围的日期等
2)笛卡尔积(Cartesian Product)
给定一组域D1,D2,…,Dn,这些域中可以有相同的。D1,D2,…,Dn的笛卡尔积为:
D1×D2×…×Dn={(d1,d2,…,dn)|diDi,i=1,2,…,n}
所有域的所有取值的一个组合
不能重复
◇元组(Tuple)
笛卡尔积中每一个元素(d1,d2,…,dn)叫作一个n元组(n-tuple)或简称元组。
◇分量(Component)
笛卡尔积元素(d1,d2,…,dn)中的每一个值di叫作一个分量。
◇基数(Cardinal number)
若Di(i=1,2,…,n)为有限集,其基数为Mi(i=1,2,…,n)
在上例中,基数:2×2×3=12,即D1×D2×D3共有2×2×3=12个元组
◇笛卡尔积的表示方法
笛卡尔积可表示为一个二维表。表中的每行对应一个元组,表中的每列对应一个域。
3)关系(Relation)
◇关系
D1×D2×…×Dn的子集叫作在域D1,D2,…,Dn上的关系,表示为 : R(D1,D2,…,Dn)
(R:关系名;n:关系的目或度(Degree))
注意:
关系是笛卡尔积的有限子集。无限关系在数据库系统中是无意义的。
由于笛卡尔积不满足交换律,即
(d1,d2,…,dn )≠(d2,d1,…,dn )
但关系满足交换律,即
(d1,d2 ,…,di ,dj ,…,dn)=(d1,d2 ,…,dj,di ,…,dn) (i,j = 1,2,…,n)
解决方法:为关系的每个列附加一个属性名以取消关系元组的有序性
◇元组
关系中的每个元素是关系中的元组,通常用t表示。
◇单元关系与二元关系
当n=1时,称该关系为单元关系(Unary relation)。
当n=2时,称该关系为二元关系(Binary relation)。
◇关系的表示
关系也是一个二维表,表的每行对应一个元组,表的每列对应一个域。
◇属性
关系中不同列可以对应相同的域,为了加以区分,必须对每列起一个名字,称为属性(Attribute)。
n目关系必有n个属性
◇码
候选码(Candidate key)
若关系中的某一属性组的值能唯一地标识一个元组,则称该属性组为候选码。
在最简单的情况下,候选码只包含一个属性。称为全码(All-key)。
在最极端的情况下,关系模式的所有属性组是这个关系模式的候选码,称为全码(All-key)。
主码
若一个关系有多个候选码,则选定其中一个为主码(Primary key),
主码的诸属性称为主属性(Prime attribute)。
不包含在任何候选码中的属性称为非码属性(Non-key attribute)。
◇三类关系
基本关系(基本表或基表):实际存在的表,是实际存储数据的逻辑表示
查询表:查询结果对应的表
视图表:由基本表或其他视图表导出的表,是虚表,不对应实际存储的数据
2关系数据库
1)关系数据库
在一个给定的应用领域中,所有实体及实体之间联系的关系的集合构成一个关系数据库。
2)关系数据库的型与值
关系数据库的型称为关系数据库模式,是对关系数据库的描述,若干域的定义,在这些域上定义的若干关系模式。
关系数据库的值是这些关系模式在某一时刻对应的关系的集合,通常简称为关系数据库。
以上就是关于数据库为什么要分库分表全部的内容,包括:数据库为什么要分库分表、什么是表间关系两个表之间的关系有几种分别是什么、Mysql数据库3种存储引擎有什么区别等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)