生产环境全链路压测 - 影子库落地
![生产环境全链路压测-影子库落地](https://static001.geekbang.org/infoq/bb/bb9cde9ad3361edee3ca335481378a8d.jpeg)
背景
在项目落地初期,大家都在询问影子库要怎么建,如果 double 一份会不会有浪费,这种情况还是需要按需来准备。先举一个例子:
示例:某企业数据库使用 365 万,如果上生产环境全链路压测的话,需要再采购 365 万的硬件,真这么做可能 owner 这个事情的部门要跳起来了,原因是成本过高。当然如果是土豪部门可以忽略
![](https://static001.geekbang.org/infoq/cf/cf32ec95880cbc449856bf1a7d4e43dd.png)
解决方案
我们的解决方案是预估出系统现有的容量情况,识别出业务热点表、配置表、日志表。将日志表剥离,业务热点表考虑存储部分天数的数据,从而达到扩磁盘,不扩机器的目的。
关于业务热点表
业务热点表是业务核心的操作表,写入和查询较多,也是压测的热点表,对于此类型的表需要能做到控制保存天数,例如核心业务表保存 3 个月,3 个月后统一转存到冷备库中。而压测中需要配置的影子库中的表,如果在资源不足的情况下,适当的控制保存天数,例如压测表中保存 1 个月诸如此类。
关于配置表
配置表多为保存一些配置信息,例如商品信息、商家信息,在电商领域通常是店小二操作的表,此类型表多为查询多,写入更新少,数据条目少,可以全量导入到影子库中。
关于操作日志类表
大家都知道日志表中,会把操作的流水写入到日志表中,日积月累这种数据量会越来越多,但是我们在生产环境压测过程中是不需要的。
![](https://static001.geekbang.org/infoq/90/905eade2f95aa8be7c95752f9246241b.png)
这个图例中使用查看了 mysql 中的 t_performance_thread_stack_data 表,它的索引大小是 1.16G,数据大小是 9 个 G,7 千万条记录,这种单表 7 千万条记录的情况,对于数据库中单个表的体积本来就是非常不合理的。再看下这个里面用的功能,记录调试业务过程中的记录数据,就业务功能来说需要存储这么多数据,可以考虑做一个水平切分,将数据库中的数据切分到多张表中,例如每月一张表、每周一张表。
下面是查询数据库中表空间体积的 sql:
mysql:
oracle:
![](https://static001.geekbang.org/infoq/6b/6bb6ddcbe40acd58fca0801d2cf5d264.png)
数据收集模板
数据库的存储的体积
![](https://static001.geekbang.org/infoq/f7/f74d0866e2cc396247ffed3de7e89a8c.png)
细化到数据表的体积
![](https://static001.geekbang.org/infoq/82/82195dd9a2eb5762c030e1ad177c2ff4.png)
与业务部门讨论:
在数据库摸底收集模板产出之后,DBA 和业务研发同学清楚目前数据库的容量情况,讨论具体影子库使用的这种方案。这里有个大前提,尽可能的模拟生产环境的数据量以及索引情况,尽可能将影子库存储在业务库的同一个库中。
版权声明: 本文为 InfoQ 作者【国隆】的原创文章。
原文链接:【http://xie.infoq.cn/article/95e51bb2bf2f9b99f6adfa747】。文章转载请联系作者。
评论