#青训营笔记创作活动#
1月17日 打卡day11
分库分表要解决的是现存海量数据访问的性能瓶颈,对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量,我们以fire100.top这个网站的资源表 t_resource为例,系统在运行初始的时候,每天只有可怜的几十个资源上传,这时使用单库、单表的方式足以支持系统的存储,数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入,系统每日产生的资源数据量暴增至十万甚至上百万级别,这时资源表数据量到达千万级,查询响应变得缓慢,数据库的性能瓶颈逐渐显现。
以MySQL数据库为例,单表的数据量在达到亿条级别,通过加索引、SQL调优等传统优化策略,性能提升依旧微乎其微时,就可以考虑做分库分表了。
既然MySQL存储海量数据时会出现性能瓶颈,那么我们是不是可以考虑用其他方案替代它?比如高性能的非关系型数据库MongoDB?
可以,但要看存储的数据类型!
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库(MySQL、Oracle等),因为它们有着NoSQL如法比拟的稳定性和可靠性,产品成熟生态系统完善,还有核心的事务功能特性,也是其他存储工具不具备的,而评论、点赞这些非核心数据还是可以考虑用MongoDB的。
1月17日 打卡day11
分库分表要解决的是现存海量数据访问的性能瓶颈,对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量,我们以fire100.top这个网站的资源表 t_resource为例,系统在运行初始的时候,每天只有可怜的几十个资源上传,这时使用单库、单表的方式足以支持系统的存储,数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入,系统每日产生的资源数据量暴增至十万甚至上百万级别,这时资源表数据量到达千万级,查询响应变得缓慢,数据库的性能瓶颈逐渐显现。
以MySQL数据库为例,单表的数据量在达到亿条级别,通过加索引、SQL调优等传统优化策略,性能提升依旧微乎其微时,就可以考虑做分库分表了。
既然MySQL存储海量数据时会出现性能瓶颈,那么我们是不是可以考虑用其他方案替代它?比如高性能的非关系型数据库MongoDB?
可以,但要看存储的数据类型!
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库(MySQL、Oracle等),因为它们有着NoSQL如法比拟的稳定性和可靠性,产品成熟生态系统完善,还有核心的事务功能特性,也是其他存储工具不具备的,而评论、点赞这些非核心数据还是可以考虑用MongoDB的。
展开
评论
点赞