本帖最后由 小江哥 于 2018-1-9 15:19 编辑
1. 分库
1.1什么是数据库分库 就是把一个库里面存放的数据拆分到多个库里面去存放 1.2 为什么要数据库分库随着互联网应用的普及,海量数据的存储变成了整个系统的瓶颈,对于一个稍微大一点的网站可能每一天的数据量都会超过千万,当数据库的数据越来越多数据库各个方面的性能都会急剧的下降,所以这个时候我们需要想办法解决最常用的就是分库分表读写分离等等 1.3如何实现数据库分库 一般来说公司会有自己的一个规定没一家公司都不太一样,例如有的公司注册的人很多要做分库的话,可能就是以user_id为准1-1000000在DB中,1000001-2000000在DB2中后面就是以此类推:例:
1.4分库之后数据查询怎么办 这里我们就需要一个叫做DB路由的东西,还是以上面的为例,你分库的时候用的是user_id那你要查询必然也要根据user_id来,比如user_id是45889那这个时候根据分库的规则肯定是在DB1中查询,这个过程叫做 DB路由,一般来说公司会有个系统或者一个工具类来判断我们应该查询哪个数据库. 注意:数据分库必然牵扯到数据分表,但是分表不一定分库 2. 分表
1.1什么是数据分表 数据分表就是将一张表的数据分成多张表来存储,和上面的分库很像 1.2为什么要数据分表 基本上和上面一样为了提高性能 1.3数据分表的两种方式 1.3.1 垂直分 你把数据库想象成一张白纸,垂直的来一刀,就是数据库的垂直分表.就是把一个数据表的字段分成了多个数据表来存放 一般情况下垂直分适合用在,一张表的字段很多的情况,我们可以根据常用和不常用的字段来进行一个垂直的切分,但是垂直 切分一般会产生一个冗余的字段来关联两张表,以方便查询 1.3.2 水平分 还是把数据库想像成一张白纸,水平的来一刀,就是数据库的水平分表.就是把一个数据表的数据分成了多个表来存放 水平切分适合单张表数据量非常大的时候,把这些数据分成几张表来存放,一般来说水平分最常用的规则是ID散列就是取id的hash值,然后看你要分成几张表就取模与几,来判定一个数据应该在哪一张表中.对于水平切分的查询也是DB路由(上面有提到) 1.3 数据切分"Shard" 这个词英文的意思是"碎片",而作为数据库相关的技术用语,似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。通过一系列的切分规则将数据水平分布到不同的DB或table中,在通过相应的DB路由或者table路由规则找到需要查询的具体的DB或者table,以进行Query操作。“sharding”通常是指“水平切分”,举个简单的例子:我们针对一个Blog应用中的日志来说明,比如日志文章(article)表有如下字段:
面对这样的一个表,我们怎样切分呢?怎样将这样的数据分布到不同的数据库中的表中去呢?我们可以这样做,将user_id为1~10000的所有的文章信息放入DB1中的article表中,将user_id为10001~20000的所有文章信息放入DB2中的 article表中,以此类推,一直到DBn。这样一来,文章数据就很自然的被分到了各个数据库中,达到了数据切分的目的。 接下来要解决的问题就是怎样找到具体的数据库呢?其实问题也是简单明显的,既然分库的时候我们用到了区分字段user_id,那么很自然,数据库路由的过程当然还是少不了user_id的。就是我们知道了这个blog的user_id,就利用这个user_id,利用分库时候的规则,反过来定位具体的数据库。比如user_id是234,利用刚才的规则,就应该定位到DB1,假如user_id是12343,利用该才的规则,就应该定位到DB2。以此类推,利用分库的规则,反向的路由到具体的DB,这个过程我们称之为“DB路由”。 平常我们会自觉的按照范式来设计我们的数据库,考虑到数据切分的DB设计,将违背这个通常的规矩和约束。为了切分,我们不得不在数据库的表中出现冗余字段,用作区分字段或者叫做分库的标记字段。比如上面的article的例子中的user_id这样的字段(当然,刚才的例子并没有很好的体现出user_id的冗余性,因为user_id这个字段即使就是不分库,也是要出现的,算是我们捡了便宜吧)。当然冗余字段的出现并不只是在分库的场景下才出现的,在很多大型应用中,冗余也是必须的,这个涉及到高效DB的设计. 1.4两者的结合的使用 很多时候单独的水平分和垂直分并不能解决问题,所以需要两者共同使用,一般这种情况下是先垂直分,在水平分,整个结构变成了下面的图示: 3.mysql读写分离
3.1什么是读写分离 所谓读写分离就是一个库用来读一个库用来写(其实不止是一个库,简单来说就是读和写的操作分开) 读写分离是一个很常用的优化手段 3.2为什么要有读写分离 正常情况下对于一个数据库来说都是”读多写少”,但是写相对于读更消耗数据库的性能.所以大牛们想到了读写分离的方案 3.3mysql的主从复制 要想实现读写分离必然要说到mysql的主从复制,因为你一旦做了读写分离必然要面临的第一个问题就是数据库数据怎么同步 我们往我们的写库里面添加了数据但是读库不知道,这肯定是不行的 所以我们要配置mysql的主从复制,一般来说我们把写库配置成主库读库配置成从库,我们往主库里面添加了数据之后,我们可以通过主库的日志(也可以理解为配置文件)方式来把你添加的数据同步到从库中去这个时候就能够保证数据同步,但是这个过程是有时间差的而且无法避免流程如下图:
2.4如何实现读写分离 2.4.1 我们可以配置多个数据源通过程序的手动控制来控制读写 例如:我们可以使用spring的aop来实现,在进入service之前,我可以加一个切面来判断这个操作是读还是写,例如进根据方法名,一般query,find,get开头的都是查询,走读库,其他的走写库 2.4.2我们可以引入中间键(有点像activemq)中间键可以自动的帮我们实现 关于数据库的读写分离和分表分库我们就介绍到这里了.下次再见.
校区捷报众览群雄,唯我杭城独秀—一贴汇总杭州校区所有就业薪资
|