参数表上那个数字，是拿什么数据跑出来的

结论先行：「每秒处理百万级」这类说法本身不含信息，因为缺了测试条件。同一个平台，日志字段从二十个增加到八十个、冷数据比例从三成升到八成、查询跨度从一个小时拉长到三十天、并发从一个人变成十个人，测出来的数字可以相差数倍。采购与验收时要把那个数字还原成四个条件：什么数据、什么分布、什么跨度、几个人同时用。四项对不上，数字就不可比。

本文只谈性能数字该在什么条件下被验证，不谈引擎选型该选自研还是开源，也不谈集群规模怎么按数据量定。

四个条件，缺一个数字就失真

条件一：日志的字段数量

存储与检索的成本，跟每条的字段数关系很大，跟条数关系反而没那么大。一条结构规整、字段十个的安全设备日志，与一条嵌套很深、字段上百的应用日志，同一条数下的工作量不在一个量级。测试数据的字段结构如果比现网简单，测出来的速率就会偏乐观。

核对办法很土但有效：从现网随机取一小时的真实日志，问对方能不能用这份数据跑一遍。

条件二：冷热比例

热数据在高速存储上，查询快；冷数据在低成本介质上，查询慢但便宜。如果报价里的性能数字是在全热数据条件下测的，那么在真实的比例下会明显打折。现网常见的形态是：最近七天的数据被频繁查，更早的数据几乎不查但必须留着。所以测试数据的冷热比应该按现网估，而不是全给热的。

条件三：查询跨度与聚合复杂度

「检索千亿条日志」和「在千亿条日志里做一次分组统计」是两件事。前者是找到，后者是算。跨度越长、分组维度越多，耗时增长得越快。验收时如果只测了按关键字找一条日志，那份结论无法支撑日常的月度报表场景。

条件四：并发

单用户测出来的响应时间，在十个人同时查的时候通常不成立。安全运营与运维是两个不同的使用高峰，重保期间还会叠加。验收测试应该按实际同时在线的分析人员数量来压，而不是一个人点一下。

把验收测试写成一张表

这四行里，第三行最容易被跳过，也最值得测。日常排障用热数据，月度与年度报表用冷数据；冷数据一旦慢到不可用，报表就会变成「每月导出一次、跑一晚上」的固定动作。

两个常见的话术陷阱

其一，用峰值代替常态。某个瞬时峰值确实到过那个数字，但那是一次压测的尖峰，不代表持续能力。要问的是持续入库能稳在多少、稳多久。

其二，用引擎能力代替交付能力。引擎的基准测试成绩与交付到你这套集群上的表现不是一回事——后者取决于节点规格、磁盘、网络、参数调优，以及实施方有没有按你的数据特征做适配。同一款引擎，不同实施方交付出来的效果可以差很远。

边界与前提

三点说明。其一，本文所述性能差异量级为工程经验归纳，不构成对任何产品性能的判断，具体表现须以本项目实测为准。其二，测试数据的取法涉及客户数据，须在脱敏后使用，并遵守本单位的数据管理规定。其三，验收标准的最终形态应与合同约定的服务水平挂钩，本文的四项条件可作为拟定标准的参考维度。

深圳市奇摩计算机有限公司在日志平台交付时，习惯把上面四项条件写进验收方案，先取现网数据跑一遍再签字。预约咨询，可以按你手上的参数表一起把这四项补齐。