分表与分库使用场景以及设计方式

一. 分表

场景:对于大型的互联网应用来说,数据库单表的记录行数可能达到千万级甚至是亿级,并且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构,

只能够对数据库的读进行扩展,而对数据库的写入操作还是集中在Master上,并且单个Master挂载的Slave也不可能无限制多,Slave的数量受到Master能力和负载的限制。

因此,需要对数据库的吞吐能力进行进一步的扩展,以满足高并发访问与海量数据存储的需要!

对于访问极为频繁且数据量巨大的单表来说,我们首先要做的就是减少单表的记录条数,以便减少数据查询所需要的时间,提高数据库的吞吐,这就是所谓的分表!

在分表之前,首先需要选择适当的分表策略,使得数据能够较为均衡地分不到多张表中,并且不影响正常的查询!

对于互联网企业来说,大部分数据都是与用户关联的,因此,用户id是最常用的分表字段。因为大部分查询都需要带上用户id,这样既不影响查询,又能够使数据较为均衡地

分布到各个表中(当然,有的场景也可能会出现冷热数据分布不均衡的情况),如下图:

假设有一张表记录用户购买信息的订单表order,由于order表记录条数太多,将被拆分成256张表。

拆分的记录根据user_id%256取得对应的表进行存储,前台应用则根据对应的user_id%256,找到对应订单存储的表进行访问。

这样一来,user_id便成为一个必需的查询条件,否则将会由于无法定位数据存储的表而无法对数据进行访问。

注:拆分后表的数量一般为2的n次方,就是上面拆分成256张表的由来!

假设order表结构如下:

create table order_(order_id bigint(20) primary key auto_increment,user_id bigint(20),user_nick varchar(50),auction_id bigint(20),auction_title bigint(20),price bigint(20),auction_cat varchar(200),seller_id bigint(20),seller_nick varchar(50))

那么分表以后,假设user_id = 257,并且auction_id = 100,需要根据auction_id来查询对应的订单信息,则对应的SQL语句如下:

select * from order_1 where user_id=257 and auction_id = 100;

其中,order_1是根据257%256计算得出,表示分表之后的第一张order表。

二. 分库

场景:分表能够解决单表数据量过大带来的查询效率下降的问题,但是,却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问,当数据库master

服务器无法承载写操作压力时,不管如何扩展slave服务器,此时都没有意义了。

因此,我们必须换一种思路,对数据库进行拆分,从而提高数据库写入能力,这就是所谓的分库!

与分表策略相似,分库可以采用通过一个关键字取模的方式,来对数据访问进行路由,如下图所示:

还是之前的订单表,假设user_id 字段的值为258,将原有的单库分为256个库,那么应用程序对数据库的访问请求将被路由到第二个库(258%256 = 2)。

三. 分库分表

场景:有时数据库可能既面临着高并发访问的压力,又需要面对海量数据的存储问题,这时需要对数据库既采用分表策略,又采用分库策略,以便同时扩展系统的

并发处理能力,以及提升单表的查询性能,这就是所谓的分库分表。

分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂,一种分库分表的路由策略如下:

1. 中间变量 = user_id % (分库数量 * 每个库的表数量)

2. 库 = 取整数 (中间变量 / 每个库的表数量)

3. 表 = 中间变量 % 每个库的表数量

同样采用user_id作为路由字段,首先使用user_id 对库数量*每个库表的数量取模,得到一个中间变量;然后使用中间变量除以每个库表的数量,取整,便得到

对应的库;而中间变量对每个库表的数量取模,即得到对应的表。

分库分表策略详细过程如下:

假设将原来的单库单表order拆分成256个库,每个库包含1024个表,那么按照前面所提到的路由策略,对于user_id=262145 的访问,路由的计算过程如下:

1. 中间变量 = 262145 % (256 * 1024) = 1

2. 库 = 取整 (1/1024) = 0

3. 表 = 1 % 1024 = 1

这就意味着,对于user_id=262145 的订单记录的查询和修改,将被路由到第0个库的第1个order_1表中执行!!!

原文发布于微信公众号 - java工会(javagonghui)

原文发表时间:2018-08-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据库

游戏用户中心开发

用户中心最主要的功能就是管理用户的注册和登陆,登陆成功之后生成对应的token,并负责token的验证。当一个用户注册或登陆成功之后,它的信息会在用户中心服务中...

21080
来自专栏性能与架构

Mysql 压力测试工具 mysqlslap

mysqlslap 是 Mysql 自带的压力测试工具,可以模拟出大量客户端同时操作数据库的情况,通过结果信息来了解数据库的性能状况 mysqlslap 的一个...

75950
来自专栏java工会

如何恢复oracle中误删除表(drop掉的)?

以下是一个不该发生却经常发生的情况:用户删除了一个非常重要的表 ― 当然是意外地删除 ― 并需要尽快地恢复。(在某些时候,这个不幸的用户可能就是 DBA!)

9520
来自专栏IT大咖说

知数堂联合创始人叶金荣:MySQL 5.7新时代

摘要 MySQL 5.7版本新增了很多特别实用的功能,截止目前已经发布5.7.17版本,也越来越成熟了,而且Group Replication也GA了。就让我们...

40560
来自专栏铭毅天下

干货 | Elasticsearch索引生命周期管理探索

Elasticsearch上海Meetup中ebay工程师提了索引生命周期管理的概念。的确,在Demo级别的验证阶段我们数据量比较小,不太需要关注索引的生命周期...

31220
来自专栏CSDN技术头条

应当使用 SQLite 的五个原因

SQLite 是非常优秀的数据库,能够在真实的生产环境中完成一些真正的工作。本文将列出五个我认为在2016年应当选用 SQLite 的原因。 ? 便于管理 不知...

29180
来自专栏Netkiller

数据库与图片完美解决方案

数据库与图片完美解决方案 电商商品图品与数据库脏数据完美解决方案 摘要 你是是不是在开发中常常遇到,删除了数据库记录后,发现该记录对应的图片没有删除,或者删除了...

35370
来自专栏PHP在线

优化 MySQL: 3 个简单的小调整

如果你不改变 MySQL 的缺省配置,你的服务器的性能就像题图的坏在一档的法拉利一样 “虎落平阳被犬欺” … 我并不期望成为一个专家级的 DBA,但是,在我优化...

28870
来自专栏文渊之博

参数化(一):计划缓存

  简介   很多时候,当我执行查询调优的时候,引发查询性能糟糕的问题一般都是与参数化相关的。一方面,参数化是查询处理器核心的基本主题。它能显著影响查询性能。另...

18180
来自专栏java工会

分表与分库使用场景以及设计方式

场景:对于大型的互联网应用来说,数据库单表的记录行数可能达到千万级甚至是亿级,并且数据库面临着极高的并发访问。采用Master-Slave复制模式的...

14010

扫码关注云+社区

领取腾讯云代金券