生产环境全链路压测-影子库落地

背景

在项目落地初期，大家都在询问影子库要怎么建，如果 double 一份会不会有浪费，这种情况还是需要按需来准备。先举一个例子：

示例：某企业数据库使用 365 万，如果上生产环境全链路压测的话，需要再采购 365 万的硬件，真这么做可能 owner 这个事情的部门要跳起来了，原因是成本过高。当然如果是土豪部门可以忽略

解决方案

我们的解决方案是预估出系统现有的容量情况，识别出业务热点表、配置表、日志表。将日志表剥离，业务热点表考虑存储部分天数的数据，从而达到扩磁盘，不扩机器的目的。

关于业务热点表

业务热点表是业务核心的操作表，写入和查询较多，也是压测的热点表，对于此类型的表需要能做到控制保存天数，例如核心业务表保存 3 个月，3 个月后统一转存到冷备库中。而压测中需要配置的影子库中的表，如果在资源不足的情况下，适当的控制保存天数，例如压测表中保存 1 个月诸如此类。

关于配置表

配置表多为保存一些配置信息，例如商品信息、商家信息，在电商领域通常是店小二操作的表，此类型表多为查询多，写入更新少，数据条目少，可以全量导入到影子库中。

关于操作日志类表

大家都知道日志表中，会把操作的流水写入到日志表中，日积月累这种数据量会越来越多，但是我们在生产环境压测过程中是不需要的。

这个图例中使用查看了 mysql 中的 t_performance_thread_stack_data 表，它的索引大小是 1.16G，数据大小是 9 个 G，7 千万条记录，这种单表 7 千万条记录的情况，对于数据库中单个表的体积本来就是非常不合理的。再看下这个里面用的功能，记录调试业务过程中的记录数据，就业务功能来说需要存储这么多数据，可以考虑做一个水平切分，将数据库中的数据切分到多张表中，例如每月一张表、每周一张表。

下面是查询数据库中表空间体积的 sql：

mysql：

oracle：

数据收集模板

数据库的存储的体积

细化到数据表的体积

与业务部门讨论：

在数据库摸底收集模板产出之后，DBA 和业务研发同学清楚目前数据库的容量情况，讨论具体影子库使用的这种方案。这里有个大前提，尽可能的模拟生产环境的数据量以及索引情况，尽可能将影子库存储在业务库的同一个库中。