CostBench首测：ClickHouse实时性能每美元高出412-1996倍

从新数据到快速查询的路径塑造了每美元性能

一个实时分析系统永远不会在已完成的数据集上工作。当用户、应用程序和代理查询可能已经跨越数十亿或万亿行的数据时，新行不断到达。每个新行都必须准备好供查询使用，同时这些查询继续运行。

CostBench的首批结果显示，查询引擎只是区分云数据仓库的一部分：

系统在将传入数据从到达带到查询就绪状态的成本和效率方面差异巨大。

在持续负载下，这项工作对每美元性能的影响可能与查询执行本身一样大：它带有自己的直接成本，并且它产生的状态决定了查询引擎还剩下多少工作。

这第一轮端到端测试使用基于推送的摄取测试了ClickHouse Cloud、Snowflake、BigQuery和Redshift Serverless。

CostBench测量了完整的工作负载——摄取、持续的查询就绪工作以及聚合和钻取查询服务——所有这些同时运行。这篇文章首先解释了查询就绪的含义，然后展示了基准如何衡量这两种效应，并呈现了总体结果。后续的1:1文章将追踪这些结果，逐一分析每个提供商的架构和计费模式。

是什么让数据做好查询准备

考虑一个常见的分析模式：过滤一个连续的行范围，例如web分析表中特定日期的所有事件，然后分组并聚合结果：

SELECT    URL,COUNT(*) AS pageviews,COUNT(DISTINCTUser) AS usersFROM hitsWHEREDay='D2'GROUPBY URL;

这正是分析系统被构建为快速运行的查询类型。为此，它们通过查询就绪来保持数据最小化查询引擎必须读取的数据量以及必须做的重复工作量。

对于像这样的典型分析查询，这转化为三个要求：按列存储数据，组织数据以便块修剪，并预聚合重复计算。

按列存储数据

大多数分析查询不需要表中的每一列。它们可能按一列过滤，按另一列分组，并从第三列计算聚合。示例查询仅使用Day、User和URL。

列式存储让引擎直接读取这三列并跳过所有其他列，即使表包含数百列。

组织数据以便块修剪

分析引擎按块处理列值，这实现了高效的向量化执行。

块也是修剪的单位。在读取块之前，引擎检查其元数据，并在其值落在查询过滤器之外时跳过它。当物理布局将相似的值放在一起时，修剪效果最好，例如通过排序过滤的列。在下面的示例中，按Day排序让引擎只读取D2块并跳过D1和D3块。

预聚合重复计算

在数十亿或万亿行中，为每个查询扫描和聚合原始数据对于交互式分析来说太慢了。

预聚合将重复工作移出每个查询。它们维护一个小得多的汇总行集，减少了查询时读取的数据以及执行的分组和聚合。汇总保留了查询所需的分组维度和聚合结果，允许查询引擎组合准备好的结果，而不是对单个事件重复这些计算。

对于欺诈检测等时间敏感用例，预聚合行还必须与事件级数据保持同步，理想情况下在新事件变得可查询的同时更新。

由于分析查询通常仍然过滤这些汇总行，预聚合数据也受益于便于修剪的物理布局。

下面的示例将九个事件转换为按Day排序的三行日汇总行。对于WHERE Day = 'D1'，引擎只读取D1行并跳过D2和D3行。

总之，列式存储、便于修剪的布局和最新的预聚合使分析数据做好查询准备。