千万量级的数据,用 MySQL 要怎么存?算法
初学者在看到这个问题的时候,可能首先想到的是 MySQL 一张表到底能存放多少条数据?数据库
根据 MySQL 官方文档的介绍,MySQL 理论上限是 (232)2 条数据,然而实际操做中,每每还受限于下面两条因素:后端
那有人会说,只要个人数据大小不超过上限,数据行数也不超过上限,是否是就没有问题了?其实不尽然。架构
在实际项目中,通常没有哪一个项目真的触发到 MySQL 数据的上限了,由于当数据量变大了以后,查询速度会慢的吓人,而通常这个时候,你的数据量离 MySQL 的理论上限还远着呢!前后端分离
传统的企业应用通常数据量都不大,数据也都比较容易处理,可是在互联网项目中,上千万、上亿的数据量并不鲜见。在这种时候,还要保证数据库的操做效率,咱们就不得不考虑数据库的分库分表了。分布式
那么接下来就和你们简单聊一聊数据库分库分表的问题。微服务
看这个名字就知道,就是把一个数据库切分红 N 多个数据库,而后存放在不一样的数据库实例上面,这样作有两个好处:性能
通常来讲,数据库的切分有两种不一样的切分规则:3d
接下来咱们就对这两种不一样的切分规则分别进行介绍。视频
先来一张简单的示意图,你们感觉一下什么是水平切分:
假设个人 DB 中有 table-一、table-2 以及 table-3 三张表,水平切分就是拿着个人绝世好剑,对准黑色的线条,砍一剑或者砍 N 剑!
砍完以后,将砍掉的部分放到另一个数据库实例中,变成下面这样:
这样,本来放在一个 DB 中的 table 如今放在两个 DB 中了,观察以后咱们发现:
这就是数据库的水平切分,也能够理解为按照数据行进行切分,即按照表中某个字段的某种规则来将表数据分散到多个库之中,每一个表中包含一部分数据。
这里的某种规则都包含哪些规则呢?这就涉及到数据库的分片规则问题了,这个松哥在后面的文章中也会和你们一一展开详述。这里先简单说几个常见的分片规则:
详细的用法,将在后面的文章中和你们仔细说。
先来一张简单的示意图,你们感觉一下垂直切分:
所谓的垂直切分就是拿着个人屠龙刀,对准了黑色的线条砍。砍完以后,将不一样的表放到不一样的数据库实例中去,变成下面这个样子:
这个时候咱们发现以下几个特色:
这就是垂直切分。通常来讲,垂直切分咱们能够按照业务来划分,不一样业务的表放到不一样的数据库实例中。
老实说,在实际项目中,数据库垂直切分并非一件容易的事,由于表之间每每存在着复杂的跨库 JOIN 问题,那么这个时候如何取舍,就要考验架构师的水平了!
经过上面的介绍,相信你们对于水平切分和垂直切分已经有所了解,优缺点其实也很明显了,松哥再来和你们总结一下。
虽然 MySQL 中数据存储的理论上限比较高,可是在实际开发中咱们不会等到数据存不下的时候才去考虑分库分表问题,由于在那以前,你就会明显的感受到数据库的各项性能在降低,就要开始考虑分库分表了。
好了,今天主要是向你们介绍一点概念性的东西,算是咱们分布式数据库中间件正式出场前的一点铺垫。
参考资料:
关注公众号【江南一点雨】,专一于 Spring Boot+微服务以及先后端分离等全栈技术,按期视频教程分享,关注后回复 Java ,领取松哥为你精心准备的 Java 干货!