为压测指标聚合选用专用时序数据库：写入速度与聚合查询的双重契合

压测过程会产生大量响应时间数据，要从这些原始数据计算出TP90、TP50、QPS、最大/平均响应时间这些聚合指标，存储和查询这一层的选型直接决定了整个工具的可用性。这套压测工具选择了InfluxDB而不是MongoDB这类更常见的通用文档数据库，理由有两点：一是InfluxDB底层是KV模型，能够兼容RocksDB、Redis这类常见KV引擎，写入速度快，能够承受压测场景下短时间内产生的大量数据点；二是InfluxDB对时序数据的聚合运算做了专门优化，像TP90这样的百分位数聚合，只需要一行SQL就能完成（SELECT PERCENTILE(response_time,90) FROM test_series GROUP BY time(10s)），不需要额外写代码去实现百分位数的计算逻辑。团队也提到过和Druid的对比：两者都能快速完成数据聚合，但Druid更偏向大数据分析场景，而InfluxDB作为专门的时序数据库，更贴合”记录一连串带时间戳的性能指标、再按时间窗口聚合”这个压测场景的具体形态。这个选型案例给出了一条存储选型的实用原则：当要处理的数据带有明显的”时间序列+聚合统计”特征时（不只是压测指标，监控指标、传感器数据、业务时序统计都属于这类），应当优先考虑专门为这类场景设计的时序数据库，而不是默认用一个通用的文档/关系型数据库去凑合——通用存储虽然能存下这些数据，但缺少针对时序聚合场景的专门优化（如内置的百分位数函数、按时间窗口聚合的原生语法），会导致本该用一行SQL完成的操作，变成需要在应用层额外写代码实现的负担。