一招鲜玩转十亿级别Mysql存储

·  阅读 452

Mysql是业内最常用的数据库之一,特别是对于中小企业来说,mysql绝对是首选。

为什么要用Mysql,其它的分布式数据库不香吗?

市面上没有比Mysql优秀的数据库吗?

当然不是,从各个数据库的纸面数据来看,比mysql优秀的数据库数不胜数。为什么Mysql能够牢牢的占据市场份额呢?

我觉得有以下几个原因

  1. 免费、开源
  2. 生态完善
  3. 长期流行,基本上所有人都会
  4. 各项性能均衡(不像很多数据库,要么读能力强、要么写能力强、要么不支持复杂的查询)
  5. 成本低

让我来找一个词来形容Mysql,我觉得就是中庸。一个Mysql数据库就能满足绝大多数企业的读写需求。

为什么不用分布式数据库?

我觉得这个问题就像是在问:何不食肉糜?

从长远来看,分布式数据库绝对是主流,但是现阶段还不够成熟,分布式数据库的人才非常的稀缺。

大公司很多都已经开始用分布式数据库了,因为他们有自己的中间件团队,出了问题有能力去解决问题。

但是对于绝大多数企业来说,分布式数据库绝对不是他们玩儿的起的,这个需要专业的运维人员和专门的研发团队去解决遇到的问题,中小企业是很难负担得起这样的人力成本的。

面对快速增长的数据量,Mysql能否满足存储查询需求?

答案是肯定,多了不敢说,单纯使用Mysql我们支持了20亿的订单存储查询,并且性能还是比较优秀的,还远没有到达存储上限

我想这个数据量还是很有说服力的,能达到这个数据量的公司绝对不多。

Mysql如何做海量数据的存储

再说这个问题之前,我先介绍一下我们以前的数据量级以及存储方案

订单表里面的数据是2亿+,有100+字段,20+索引,没有分库分表,还能够满足业务需求(看到这儿可能有同学就觉得我吹牛逼了,要不是我亲眼所见,我也不信!)

为什么这么大的数据量,单表就能支持?

因为疯狂堆机器配置,我们机器配置:128核、256G、TB级固态硬盘。

之后我们重构了订单,把订单表拆到了接近20张表里面,然后通过订单号作为分表键,分了16张表,所有表里面只有订单号一个索引。

分表容易,但是分表之后却会带来一些严重的问题

  1. 条件查询怎么查?
  2. 如何做分页?

我们这边是用了ES来解决,但是我不打算说这个方案。

我们兄弟部门用的是Mysql来解决,他们有20亿+订单,目前是分了8个库,没有分表。

我们两种方案其实都有一个核心思想:

敲黑板、划重点、记住了、考试要考!

为索引建立索引

我们可以回想下,实际上InnoDB也是应用了这种思想。

我们来看一下这个思想如何应用

假设一个电商系统,我们按照订单号对其进行了分库分表。

假如有以下两个表

order

id order_number user_id

order_product

Id order_number produc_id

订单表和订单商品表都按照order_number 进行库分表,我们可以看到,通过order_number我们可以很轻易的查询出订单详情,但是我们想做一点别的查询就回非常的困难。

比如说我想查找某用户的所有订单,如何查?如果分了1024张表,我们是不是要把1024张表全部查完才知道用户有多少订单?当然,没人会那么去玩儿。

我们可以再建立一张索引表,分表键是user_id,这样一个用户的所有信息就会落到一张表上面,然后我们通过一次查询就能拿到所有的订单,我们还能通过这个索引表进行分页查询。

在拿到订单号之后,我们就能通过订单号精确查找到所有的订单。

还可以通过时间分,通过商品分等等,总之核心思想就是为索引建立索引

通过这种方式,我们建立多个索引表,就可以实现较为复杂的查询。

当然这种方案看起来比较笨,这是由于mysql天然的缺陷造成的,从长远来看,mysql终将走向没落。

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改