北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!

千万量级的数据,用 MySQL 要怎么存?

初学者在看到这个问题的时候,可能首先想到的是 MySQL 一张表到底能存放多少条数据?

根据 MySQL 官方文档的介绍,MySQL 理论上限是 (232)2 条数据,然而实际操作中,往往还受限于下面两条因素:

myisam_data_pointer_size,MySQL 的 myisam_data_pointer_size 一般默认是 6,即 48 位,那么对应的行数就是 248-1。

表的存储大小 256TB

那有人会说,只要我的数据大小不超过上限,数据行数也不超过上限,是不是就没有问题了?其实不尽然。

在实际项目中,一般没有哪个项目真的触发到 MySQL 数据的上限了,因为当数据量变大了之后,查询速度会慢的吓人,而一般这个时候,你的数据量离 MySQL 的理论上限还远着呢!

传统的企业应用一般数据量都不大,数据也都比较容易处理,但是在互联网项目中,上千万、上亿的数据量并不鲜见。在这种时候,还要保证数据库的操作效率,我们就不得不考虑数据库的分库分表了。

那么接下来就和大家简单聊一聊数据库分库分表的问题。

数据库切分

看这个名字就知道,就是把一个数据库切分成 N 多个数据库,然后存放在不同的数据库实例上面,这样做有两个好处:

降低单台数据库实例的负载

可以方便的实现对数据库的扩容

一般来说,数据库的切分有两种不同的切分规则:

水平切分

垂直切分

接下来我们就对这两种不同的切分规则分别进行介绍。

水平切分

先来一张简单的示意图,大家感受一下什么是水平切分:

北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!

假设我的 DB 中有 table-1、table-2 以及 table-3 三张表,水平切分就是拿着我的绝世好剑,对准黑色的线条,砍一剑或者砍 N 剑!

砍完之后,将砍掉的部分放到另外一个数据库实例中,变成下面这样:

北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!


北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!

这样,原本放在一个 DB 中的 table 现在放在两个 DB 中了,观察之后我们发现:

两个 DB 中表的个数都是完整的,就是原来 DB 中有几张表,现在还是几张。

每张表中的数据是不完整的,数据被拆分到了不同的 DB 中去了。

这就是数据库的水平切分,也可以理解为按照数据行进行切分,即按照表中某个字段的某种规则来将表数据分散到多个库之中,每个表中包含一部分数据。

这里的某种规则都包含哪些规则呢?这就涉及到数据库的分片规则问题了,这个松哥在后面的文章中也会和大家一一展开详述。这里先简单说几个常见的分片规则:

按照日期划分:不容日期的数据存放到不同的数据库中。

对 ID 取模:对表中的 ID 字段进行取模运算,根据取模结果将数据保存到不同的实例中。

使用一致性哈希算法进行切分。

详细的用法,将在后面的文章中和大家仔细说。

垂直切分

先来一张简单的示意图,大家感受一下垂直切分:

北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!

所谓的垂直切分就是拿着我的屠龙刀,对准了黑色的线条砍。砍完之后,将不同的表放到不同的数据库实例中去,变成下面这个样子:

北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!


北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!


北冥有 Data,其名为鲲,鲲之大,一个 MySQL 放不下!

这个时候我们发现如下几个特点:

每一个数据库实例中的表的数量都是不完整的。

每一个数据库实例中表的数据是完整的。

这就是垂直切分。一般来说,垂直切分我们可以按照业务来划分,不同业务的表放到不同的数据库实例中。

老实说,在实际项目中,数据库垂直切分并不是一件容易的事,因为表之间往往存在着复杂的跨库 JOIN 问题,那么这个时候如何取舍,就要考验架构师的水平了!

优缺点分析

通过上面的介绍,相信大家对于水平切分和垂直切分已经有所了解,优缺点其实也很明显了,松哥再来和大家总结一下。

水平切分

优点

水平切分最大的优势在于数据库的扩展性好,提前选好切分规则,数据库后期可以非常方便的进行扩容。

有效提高了数据库稳定性和系统的负载能力。拆分规则抽象好, join 操作基本可以数据库做。

缺点

水平切分后,分片事务一致性不容易解决。

拆分规则不易抽象,对架构师水平要求很高。

跨库 join 性能较差。

垂直切分

优点

一般按照业务拆分,拆分后业务清晰,可以结合微服务一起食用。

系统之间整合或扩展相对要容易很多。

数据维护相对简单。

缺点

最大的问题在于存在单库性能瓶颈,数据表扩展不易。

跨库 join 不易。

事务处理复杂。

结语

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpyfwz.html