存储引擎的实测驱动选型：Devicemapper与Overlay在小文件持续写场景下的真实差异

容器存储驱动的选型，团队没有直接依赖网上流传的经验之谈（比如听说Overlay对小文件处理很擅长），而是自己动手做了实测验证。业务场景是Redis Cluster集群基于Eru部署之后，Redis的AOF（Append Only File）持久化模式会产生大量小文件的持续写入，这类负载特征对存储驱动的性能非常敏感。团队针对Devicemapper和Overlay两种驱动分别做了性能测试，结果证实了此前听到的判断：在大量小文件持续写入的场景下，Overlay的性能明显高出Devicemapper不少，这个测试结果支撑了团队把AOF这类小文件持续写场景切换到Overlay驱动的决定。但团队同时给出了一个重要的补充说明：在当前的Redis Container内存配置量级下（受限于单个Redis实例被限制在较小的内存额度内），Devicemapper和Overlay两者的实际差距其实并不明显；只有当未来单个实例的内存上限被提高、对应的数据量和文件规模同步扩大之后，Overlay相对Devicemapper的性能优势才会真正变得显著。这个补充说明揭示了一条容易被忽视但很重要的选型原则：一项性能测试得出的结论”A方案比B方案好”，往往是在特定的负载规模和特征下成立的，脱离了具体的负载量级去谈论”哪个方案更优”是不严谨的——一个方案的优势可能只在超过某个规模阈值后才会显现出来，在阈值以下两者可能几乎没有差别；做技术选型决策时，不仅要验证”这个方案在理论上/在别人的场景里表现更好”，还要结合自己当前的实际负载规模去判断这个优势此刻是否真的具有实际意义，避免为了一个在当前规模下根本体现不出来的性能优势，去承担额外的迁移和维护成本。