1. 背景 —— 公司物联网项目 海量设备通过物联网服务接入云端，设备每30s上报一次自身数据（以下称为动态数据）。 2. 问题 接入的设备数量较大时，上报的动态数据数据量过大，导致单表查询过慢。 假设有1万台设备，每台设备每30秒上报一次动态数据，那每分钟就会产生2万条数据，…

本文是《手把手项目实战系列》的第二篇文章。上一篇《手把手0基础教你搭建一套可自动化构建的微服务框架(SpringBoot+Dubbo+Docker+Jenkins)》受到巨大好评，在这里也深表感谢。应大家要求继续完成后续章节的撰写。上一篇的实战过程介绍的“高喜商城”项目其实是一…

之前不少人问我“能否分享一些分库分表相关的实践”，其实不是我不分享，而是真的经验不多🤣；和大部分人一样都是停留在理论阶段。 不过这次多少有些可以说道了。 先谈谈背景，我们生产数据库随着业务发展量也逐渐起来；好几张单表已经突破亿级数据，并且保持每天 200+W 的数据量增加。 …

本篇是上一篇《一次分表踩坑实践的探讨》，所以还没看过的朋友建议先看上文。 分表策略：哈希、时间归档等。 分表字段的选择。 数据迁移方案。 而本篇文章的背景是在我们上线这段时间遇到的一些问题并尝试解决的方案。 之前提到在分表应用上线前我们需要将原有表的数据迁移到新表中，这样才能保…

可是好景不长，业务发展是在太快了。数据库中的数据量猛增，由于所有表都在一个数据库中，导致服务器本地存储快满了。 从上图我们可以看的出来，由于表的数量较多，每个表的数据量也较大，但是还没到水平拆分的地步。目前遇到的问题是服务器的存储不够了，短期内还不用水平拆分，那么方案呼之欲出了…

之前一篇文章已经谈到了数据库集群之主从集群也就是读写分离，也提到了读写分离其实只是分担了访问的压力，但是存储的压力没有解决。 存储的压力说白了就是随着系统的演化，需求的增加，可能表的数量会逐渐增多，比如一段时间上个新功能就得加个表。并且随着用户量的增多类似用户表的行数肯定会增多…

但是实际上，数据库层面的分库分表到底是用来干什么的，他的不同的作用如何应对不同的场景，我觉得很多同学可能都没搞清楚。 假如我们现在是一个小创业公司，注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。 天哪！就这种系统，随便找一个…

从标题可以看得出来，当时我们只做了分表；还是由于业务发展，截止到现在也做了分库，目前看来都还比较顺利，所以借着脑子还记得清楚来一次复盘。 整个过程也很好理解，基本符合大部分公司的一个发展方向。 很少会有业务一开始就会设计为分库分表，虽说这样会减少后续的坑，但部分公司刚开始都是以…

随着业务规模的不断扩大，需要选择合适的方案去应对数据规模的增长，以应对逐渐增长的访问压力和数据量。 关于数据库的扩展主要包括：业务拆分、主从复制，数据库分库与分表。这篇文章主要讲述数据库分库与分表 在 大型网站应用之海量数据和高并发解决方案总结一二 一篇文章中也具体讲述了为什么…