DoubleCloud 即将停止运营。迁移到 ClickHouse 并享受限时免费迁移服务。立即联系我们 ->->

博客 / 工程

ClickHouse 与 Snowflake 实时分析对比 - 基准测试和成本分析

ClickHouse 团队

2023年9月6日

Post Header2.png

本 ClickHouse 与 Snowflake 博客系列文章分为两个部分，可以独立阅读。文章部分如下。

基准测试和成本分析 - 在这篇文章中，我们对一组用于支持提议应用程序的实时分析查询进行了基准测试。这些查询在两个系统中进行评估，使用了各种优化方法，并直接比较了成本。
对比和迁移 - 这篇文章重点概述了 ClickHouse 和 Snowflake 之间的架构异同，并回顾了 ClickHouse Cloud 中特别适合实时分析用例的功能。对于有兴趣将工作负载从 Snowflake 迁移到 ClickHouse 的用户，我们探讨了数据集的差异以及数据迁移的方法。

在这篇文章中，我们提供了一个实时分析应用程序的示例，该应用程序能够分析 Python 包随时间的下载情况。此应用程序由 PyPI 数据集提供支持，该数据集包含近 6000 亿行数据。

我们确定了支持实时应用程序的代表性查询，使用此工作负载对 ClickHouse 和 Snowflake 的性能进行了基准测试，并对成本进行了分析——运行基准测试本身的成本以及预计在生产环境中运行应用程序的持续成本。

根据此分析，我们认为，对于实时分析用例，与 Snowflake 相比，ClickHouse 可以提供显著的性能和成本改进。我们的结果表明：

ClickHouse Cloud 在生产环境中的成本效益比 Snowflake 高 3-5 倍。
与 Snowflake 相比，ClickHouse Cloud 查询速度快 2 倍以上。
ClickHouse Cloud 的数据压缩率比 Snowflake 高 38%。

复制此基准分析所需的信息和方法也可在 https://github.com/ClickHouse/clickhouse_vs_snowflake 上公开获取。

在下一节中，我们将比较 ClickHouse 和 Snowflake 的插入和查询性能，以及针对提议应用程序的查询所实现的压缩率。对于所有测试，我们都使用 us-central-1 中的 GCE 托管实例，因为下面的测试数据集最容易导出到 GCS。

我们在示例中使用 ClickHouse Cloud 服务的生产实例，总共有 177、240 和 256 个 vCPU。对于 Snowflake，我们主要使用 2X-LARGE 或 4X-LARGE 集群，我们认为它们分别拥有 256 个和 512 个 vCPU（一般认为每个节点包含 8 个 vCPU、16GiB 和 200GB 的本地存储），前者代表与我们的 ClickHouse 集群最接近的配置。虽然一些 Snowflake 配置提供了比上述 ClickHouse 集群明显的计算优势，但 ClickHouse Cloud 具有更高的cpu:memory 比例（ClickHouse 为 1:4，Snowflake 为 1:2），抵消了部分优势；但是，由于查询不是内存密集型的，因此此基准测试的抵消并不显著。

对于希望复制我们结果的用户，我们注意到这些配置在 Snowflake 中进行测试的成本可能很高——例如，将数据集加载到 Snowflake 中的成本约为 1100 美元（应用了聚簇优化），而在 ClickHouse Cloud 中约为 40 美元。用户可以选择加载子集以降低成本和/或运行有限数量的基准测试。在 ClickHouse 端，如果需要，如果无法使用 ClickHouse Cloud，则这些示例应该可以在大小相同的自管理 ClickHouse 集群上复制。

PyPI 数据集目前作为 BigQuery 中的公共表提供。此数据集中的每一行表示用户（使用 pip 或类似技术）下载的一个 Python 包。我们已将此数据导出为 Parquet 文件，并将其提供在公共 GCS 存储桶gcs://clickhouse_public_datasets/pypi/file_downloads 中。此步骤可在此处获取。此数据集的原始模式如下所示。由于嵌套结构的存在，因此选择 Parquet 作为 Snowflake 和 ClickHouse 支持的最佳导出格式。

默认情况下，导出文件大小由 BigQuery 中的分区确定。上述 GCS 文件夹中 5600 亿行的完整导出包含 19TiB 的 Parquet，分布在 150 万个文件中。虽然可以轻松导入到 ClickHouse 中，但这些小文件在导入到 Snowflake 中时会存在问题（见下文）。

为了为我们的测试提供更具成本效益的子集，我们仅导出了截至 2023 年 6 月 23 日的过去三个月的数据。为了符合 Snowflake 的最佳实践加载 Parquet 文件，我们将文件大小目标设置为 100MiB 到 150MiB 之间。为此，BigQuery 需要在导出之前复制并重新分区表。使用此处的步骤，我们能够将 8.74TiB 的数据导出为 70,608 个文件，平均大小为 129MiB。

出于本基准分析的目的，我们比较了可用于构建简单分析服务的查询，用户可以在其中输入包名称并检索包的一些有趣的趋势（理想情况下以图表形式呈现）。这包括但不限于

随时间推移的下载量，以折线图呈现。
随时间推移的每个 Python 版本的下载量，以多系列折线图呈现。
随时间推移的每个系统的下载量，例如 Linux，以多系列柱状图呈现。
项目的顶级分发/文件类型，例如 sdist 或 bdist，以饼图或柱状图呈现。

此外，应用程序可能允许用户识别

某个技术的相关子项目的总下载量（如果存在），例如 ClickHouse 的 clickhouse-connect。
特定发行版（例如 Ubuntu）的顶级项目。

这可能看起来像以下内容

以上代表了一个简单的实时应用程序，具有许多增强可能性。虽然许多实时分析应用程序比这更复杂，但以上内容使我们能够相当容易地对查询工作负载进行建模。假设我们还允许用户深入了解日期范围并更新图表，我们可以评估 Snowflake 和 ClickHouse 针对此应用程序的查询性能。

在我们的基准测试中，我们以最简单的形式对该工作负载进行建模。我们为每个图表设计一个 SQL 查询，表示用户在搜索框中键入项目名称时最初的渲染。随后的查询然后根据随机生成的日期范围过滤图表，以模拟应用程序的交互式使用。为了公平起见，两个系统的查询都使用相同的日期和项目，并按相同的顺序执行。我们使用单个线程依次执行这些查询（侧重于绝对延迟）。它不测试并发请求的工作负载；也不测试系统容量。虽然我们预计 ClickHouse 在高并发工作负载下表现良好，但此测试在执行和解释结果方面要复杂得多。

为了使此基准测试易于使用大量配置进行复制，并使结果易于解释，我们做了一些假设来限制练习的范围。可以在此处找到假设和限制的完整列表，但最值得注意的是

我们没有评估 Snowflake 的多集群仓库功能。虽然不适用于我们的测试工作负载，但这对于扩展生产应用程序的吞吐量来说将是无价的。这种方法具有优点，并且与 ClickHouse Cloud 形成对比，在 ClickHouse Cloud 中，通过添加节点来扩展服务。
Snowflake 的持久缓存增加了显著的价值。除了能够抵抗仓库重启之外，缓存是完全分布式的，并且独立于仓库。这确保了高缓存命中率。虽然 ClickHouse Cloud 的查询缓存比 Snowflake 的快，但它目前是每个节点的（尽管计划使用分布式缓存）。
我们没有评估 Snowflake 的查询加速服务。此服务将查询处理工作卸载到共享计算资源以处理特定查询，且需支付额外费用。但是，Snowflake 指出查询加速服务取决于服务器的可用性，性能改进可能会随着时间的推移而波动，因此不适合可重复的基准测试。

我们的 ClickHouse 架构如下所示

CREATE TABLE default.pypi
(
   `timestamp` DateTime64(6),
   `date` Date MATERIALIZED timestamp,
   `country_code` LowCardinality(String),
   `url` String,
   `project` String,
   `file` Tuple(filename String, project String, version String, type Enum8('bdist_wheel' = 0, 'sdist' = 1, 'bdist_egg' = 2, 'bdist_wininst' = 3, 'bdist_dumb' = 4, 'bdist_msi' = 5, 'bdist_rpm' = 6, 'bdist_dmg' = 7)),
   `installer` Tuple(name LowCardinality(String), version LowCardinality(String)),
   `python` LowCardinality(String),
   `implementation` Tuple(name LowCardinality(String), version LowCardinality(String)),
   `distro` Tuple(name LowCardinality(String), version LowCardinality(String), id LowCardinality(String), libc Tuple(lib Enum8('' = 0, 'glibc' = 1, 'libc' = 2), version LowCardinality(String))),
   `system` Tuple(name LowCardinality(String), release String),
   `cpu` LowCardinality(String),
   `openssl_version` LowCardinality(String),
   `setuptools_version` LowCardinality(String),
   `rustc_version` LowCardinality(String),
   `tls_protocol` Enum8('TLSv1.2' = 0, 'TLSv1.3' = 1),
   `tls_cipher` Enum8('ECDHE-RSA-AES128-GCM-SHA256' = 0, 'ECDHE-RSA-CHACHA20-POLY1305' = 1, 'ECDHE-RSA-AES128-SHA256' = 2, 'TLS_AES_256_GCM_SHA384' = 3, 'AES128-GCM-SHA256' = 4, 'TLS_AES_128_GCM_SHA256' = 5, 'ECDHE-RSA-AES256-GCM-SHA384' = 6, 'AES128-SHA' = 7, 'ECDHE-RSA-AES128-SHA' = 8)
)
ENGINE = MergeTree
ORDER BY (project, date, timestamp)

我们在这里应用了许多类型优化，并向架构中添加了物化列 date。这不是原始数据的一部分，纯粹是为了在主键和过滤器查询中使用而添加的。我们将嵌套结构 file、installer、implementation 和 distro 表示为命名元组。这些是分层数据结构（而不是完全半结构化数据），因此具有可预测的子列。这使我们能够应用与应用于根列相同的类型优化。

可以在此处找到有关应用的优化的完整详细信息。

我们的 Snowflake 架构

CREATE TRANSIENT TABLE PYPI (
   timestamp TIMESTAMP,
   country_code varchar,
   url varchar,
   project varchar,
   file OBJECT,
   installer OBJECT,
   python varchar,
   implementation OBJECT,
   distro VARIANT,
   system OBJECT,
   cpu varchar,
   openssl_version varchar,
   setuptools_version varchar,
   rustc_version varchar,
   tls_protocol varchar,
   tls_cipher varchar
) DATA_RETENTION_TIME_IN_DAYS = 0;

Snowflake 不需要为 VARCHAR 列指定限制，且没有性能或存储损失，从而简化了声明。我们通过将表声明为 TRANSIENT 并禁用时间旅行 (DATA_RETENTION_TIME_IN_DAYS = 0) 来优化架构。前者关闭了 Snowflake 的故障安全功能，该功能保留数据的副本七天以进行紧急恢复，这在我们的案例中不需要，并且降低了成本。ClickHouse Cloud 支持备份，提供与故障安全类似的功能 - 这些都包含在存储成本中。虽然功能强大，但允许查询历史数据的时间旅行功能对于我们的实时分析来说并不需要。

细心的读者会注意到以上架构与原始 BigQuery 架构不同，后者在 details 列下多了一个嵌套级别和一些列。我们在导出时删除了此额外级别，以简化 ClickHouse 和 Snowflake 的架构。这使得后续查询更简单。

最初我们没有指定聚簇键，但在数据加载后，我们会在进一步的实验中指定。

除非另有说明，否则这些测试是在 ClickHouse 23.6 上执行的，并且在 6 月份的前两周针对 Snowflake 执行。

根据我们的基准测试结果，在比较 Snowflake 和 ClickHouse 在此场景下的性能时，我们可以得出以下结论

启用聚簇后，ClickHouse 提供的压缩率比 Snowflake 提供的最佳压缩率高出 38%。
在我们的测试中，Snowflake 中的聚簇将压缩率提高了高达 45%。对于查询性能能够与 ClickHouse 竞争，此功能似乎至关重要，尤其是在过滤排序键时。但是，由于负责对数据进行排序的后台进程，它会带来巨大的成本。
即使 vCPU 数量相当，并且忽略 Snowflake 对数据进行聚簇所需的时间，ClickHouse 加载数据的速度也比 Snowflake 快 2 倍。这也假设文件大小对 Snowflake 来说是最佳的 - 它在较小的文件上似乎表现得更差。
查询能够利用聚簇/排序键的工作负载在实时分析用例中最常见。在这种情况下，对于热查询，ClickHouse 比具有更多 vCPU（177 对 256）并配置了等效优化聚簇键的 Snowflake 仓库快 2-3 倍。即使通过 ClickHouse 和 Snowflake 表未按其排序/聚簇的列进行聚合，这种性能差异也保留在所有测试中。
冷查询的差异不那么明显，但 ClickHouse 仍然比 Snowflake 快 1.5 到 2 倍。此外，聚簇会带来巨大的额外成本。有关更多详细信息，另请参阅成本分析。
Snowflake 中的物化视图与 ClickHouse 投影相当，尽管限制更多，并且为查询提供了强大的性能提升。对于我们有限的工作负载，这些提供的改进大于投影，但平均性能仍然比 ClickHouse 慢 1.5 倍。
在无法有效利用排序/聚簇键并被迫扫描更多数据的 GROUP BY 查询中，Snowflake 比 ClickHouse 快约 30%。这部分原因可以归因于更高的 vCPU 数量，但也归因于它能够有效地跨节点分配工作的能力。ClickHouse 中的等效功能（并行副本）目前处于实验阶段，并有待进一步改进。
对于需要完整表扫描的查询（例如 LIKE），Snowflake 提供了比 ClickHouse 更一致的查询性能，第 95/99 百分位数更低，但平均性能更高。
ClickHouse 中的二级索引在 LIKE 查询中的性能与 Snowflake 搜索优化服务相当，热性能更好，但冷性能略慢。虽然 ClickHouse 中的此功能仅略微增加了存储成本，但它在 Snowflake 中增加了大量开支 - 请参阅成本分析。

完整的测试结果详见下文。

为了评估 ClickHouse 和 Snowflake 的加载性能，我们测试了具有可比 CPU 和内存资源的几种服务和仓库大小。

可以在此处找到数据加载和使用命令的完整详细信息。我们已经优化了 ClickHouse 和 Snowflake 中的插入性能。对于前者，我们使用许多专注于分配插入并确保数据以大批量写入的设置。对于 Snowflake，我们遵循了记录的最佳实践，并确保 Parquet 文件约为 150 MiB。

为了提高 ClickHouse 插入性能，我们调整了线程数，如此处所述。这会导致形成大量分区，这些分区必须在后台合并。高分区数会对 SELECT 性能产生负面影响，因此我们报告合并以将分区数减少到 3000 以下（默认建议总数）所需的总时间 - 此处的查询此处。这是与 Snowflake 的总加载时间相比的值。

数据库	规格	节点数	每个节点的内存 (GiB)	每个节点的 vCPU	总 vCPU	总内存 (GiB)	插入线程	总时间 (s)
Snowflake	2X-LARGE	32	16	8	256	512	NA	11410
Snowflake	4X-LARGE	128	16	8	1024	2048	NA	2901
ClickHouse	708GB	3	236	59	177	708	4	15370
ClickHouse	708GB	3	236	59	177	708	8	10400
ClickHouse	708GB	3	236	59	177	708	16	11400
ClickHouse	1024GB	16	64	16	256	1024	1*	9459
ClickHouse	1024GB	16	64	16	256	1024	2	5730
ClickHouse	960GB	8	120	30	240	960	4	6110
ClickHouse	960GB	8	120	30	240	960	8	5391
ClickHouse	960GB	8	120	30	240	960	16	6133

如果我们比较 2X-LARGE (256 vCPU) 和 960GB (240 vCPU) 的最佳结果，它们具有类似的资源，ClickHouse 为相同数量的 vCPU 提供了超过 2 倍的 Snowflake 插入性能。

此测试的其他观察结果

在节点较少但每个节点的 vCPU 较多的集群（例如 708GB 配置）上，ClickHouse 会更快地完成初始插入操作。但是，然后会花费时间将分区合并到可接受的阈值以下。虽然可以在任何时间在节点上执行多个合并，但每个节点的总数是有限的。将我们的资源分散到更多节点（960GB 有 8 个 30 核节点）上，可以执行更多并发合并，从而缩短完成时间（可以通过联系支持部门在 ClickHouse Cloud 中请求这些更高级别的配置）。
为了获得最大的加载性能，Snowflake 需要与 vCPU 一样多的文件。我们假设这是因为在 Parquet 文件内读取没有并行化，与 ClickHouse 不同。虽然这在我们的数据集中不是问题，但这使得在其他场景中扩展插入具有挑战性。
Snowflake 建议确保 Parquet 文件大约为 150 MiB。包含超过 150 万个文件和 19 TiB 的完整 PyPi 数据集的平均文件大小要小得多，为 13 MiB。由于我们预计 ClickHouse 不会受到文件大小的明显影响，因此我们遵循了 Snowflake 的 150 MiB 建议。

为了测试小型 Parquet 文件的行为差异，我们将 PyPi 数据集的 690 亿行样本导入到 ClickHouse 和 Snowflake 中。此样本包含正好 3 个月的数据，可以在存储桶 gs://clickhouse_public_datasets/pypi/file_downloads/2023_may_aug/ 中找到，包含 1.06TiB 的 Parquet 数据，分布在 109,448 个文件中，平均大小为 10MiB。虽然 Snowflake 的总加载时间似乎不受这些较小文件大小的影响，但 ClickHouse 实际上受益匪浅，并且性能超过 Snowflake 约 35%。虽然此测试是在 ClickHouse 23.8 的较新版本上进行的，但进一步的测试表明 ClickHouse 在 10MiB 文件上的速度比 150MiB 文件快。我们没有测试其他文件大小。完整结果可以在这里找到。

Snowflake 的加载时间与 vCPU 数量呈线性改进。这意味着用户的总成本保持不变，例如 4X-LARGE 仓库是 2X-LARGE 仓库成本的两倍，但加载时间减半。用户可以依次在完成加载后使仓库空闲，从而产生相同的总费用。ClickHouse Cloud 的新功能，SharedMergeTree，也确保插入性能随资源线性扩展。虽然上述基准测试结果使用的是 ClickHouse 标准的 MergeTree（由于这些基准测试的执行时间），但演示使用此数据集的 SharedMergeTree 线性可扩展性的结果示例可以在这里找到。
以上内容不包括 Snowflake 的任何聚类时间。如下所示，聚类对于查询性能与 ClickHouse 竞争至关重要。但是，如果将聚类时间包含在比较中，Snowflake 的插入时间将显著高于 ClickHouse——这很难精确测量，因为聚类是异步的，并且其调度是非确定性的。

此测试的更多观察结果可以在这里找到。

我们之前的 ClickHouse 架构主要针对最大压缩进行了优化。如下所示，可以通过对 date 和 timestamp 列应用增量编解码器来进一步改进它，尽管这已显示出对冷查询性能造成副作用。

默认情况下，Snowflake 架构不包含聚类。聚类通过设置聚类键进行配置，聚类键的选择会严重影响数据压缩。为了彻底评估 Snowflake 压缩率，我们测试了各种聚类键，并记录了每个键产生的总压缩数据大小，如下所示。

有关我们的压缩结果以及测量方法的完整详细信息，请参见这里。

数据库	ORDER BY/CLUSTER BY	总大小 (TiB)	Parquet 压缩率
Snowflake	-	1.99	4.39
Snowflake	(to_date(timestamp), project)	1.33	6.57
Snowflake	(project)	1.52	5.75
Snowflake	(project, to_date(timestamp))	1.77	4.94
Snowflake	(project, timestamp)*	1.05	8.32
ClickHouse	(project, date, timestamp)	0.902	9.67
ClickHouse	(project, date, timestamp) + 增量编解码器	0.87	10.05

大多数可选查询性能

最优压缩

请注意，我们无法识别 Snowflake 的未压缩大小，也无法提供类似于 ClickHouse 的压缩率。因此，我们计算了相对于 Parquet 的压缩率。

在我们的用例中，Snowflake 中的聚类对于良好的压缩和查询性能至关重要。为我们的 Snowflake 架构选择的最佳聚类键使数据大小减少了 40%。尽管包含了额外的 date 列，但 ClickHouse 的最佳压缩仍然比最优的 Snowflake 配置好近 20%（0.87TiB 对 1.05TiB）。

也就是说，就压缩而言，Snowflake 性能最佳的聚类键并没有带来最佳的 Snowflake 查询性能。因此，Snowflake 用户需要权衡——优化压缩（从而降低存储成本）或获得更快的查询。

对于我们的基准分析，目标是支持实时分析工作负载，为此快速查询至关重要。因此，在我们的其余基准测试中使用的聚类键是比压缩更能提高查询速度的聚类键，并且还遵循 Snowflake 发布的最佳实践，建议首先使用基数较低的列。这是 (to_date(timestamp), project) 聚类键。

根据针对查询速度优化的配置和架构，我们的结果表明 ClickHouse Cloud 的压缩性能比 Snowflake 高 38%（0.902TiB 对 1.33TiB）。

如Snowflake 文档所述，聚类会带来权衡。虽然可以提高查询性能，但用户将因使用此异步服务而被收取积分。我们尝试在下面捕获每个上述聚类键所需的总积分（和成本）以及聚类稳定所需的时间。此处消耗的时间是一个估计值，因为 Snowflake 在其AUTOMATIC_CLUSTERING_HISTORY 视图中仅提供小时级粒度。请参阅此处以获取用于计算聚类成本的查询。

CLUSTER BY	花费时间 (分钟)	已聚类行数	已聚类字节数	已使用积分	总成本（假设为标准）
(to_date(timestamp), project)	540	53818118911	1893068905149	450	$990
(project)	360	41243645440	1652448880719	283	$566
(project, to_date(timestamp))	180	56579552438	1315724687124	243	$486
(project, timestamp)	120	50957022860	1169499869415	149	$298

上表中的时间可以考虑加入插入性能测试。有效的聚类（其中大量字节已聚类）似乎在 Snowflake 中产生了很大的积分和时间成本。

ClickHouse 中的等效功能（使用 ORDER BY）不会产生额外费用，并且所有表默认都需要它。可以通过投影向 ClickHouse 表添加其他排序。在这种情况下，用户仅支付额外存储费用。投影和排序仅在插入时对数据进行排序并在后台执行合并时产生增量的计算和内存开销。后台进程使用的 CPU 和内存优先级低于查询，通常利用现有服务上的空闲资源。这些后台操作的完成对于查询运行和观察更新的数据不是必需的，但可以提高未来查询的性能。

我们模拟每个提议的可视化的负载以评估查询性能。我们在下面总结了结果，并为希望复制基准测试的人提供了完整分析的链接。我们假设

Snowflake 上已完成聚类，并且 ClickHouse 中的分区数低于 3000。
所有查询都执行 3 次以获得冷热执行时间。我们认为热结果是最快的时间，而冷结果是最慢的时间。
在 ClickHouse 上执行之前，我们清除任何文件系统缓存，即 SYSTEM DROP FILESYSTEM CACHE ON CLUSTER 'default'。Snowflake 上似乎无法执行此操作，因此我们暂停并恢复了仓库。
除非另有说明，否则 Snowflake 和 ClickHouse 的查询缓存都已禁用。ClickHouse Cloud 中的查询缓存默认情况下是禁用的。Snowflake 的缓存默认情况下是启用的，必须禁用，即 ALTER USER <user> SET USE_CACHED_RESULT = false;。
所有查询在计算过去 90 天的数据时都使用绝对日期作为数据的上限。这允许测试在任何时间运行并利用查询缓存（如果已启用）。

此查询的结果旨在显示过去 90 天内每天的下载量，针对选定的项目。对于前 100 个项目，会发出计算此聚合的查询。然后将更窄的时间过滤器应用于随机时间范围（两个数据库使用相同的随机值），按产生大约 100 个存储桶的间隔进行分组（因此任何图表点都可以合理地呈现），从而模拟用户向下钻取。这将导致总共 200 个查询。

SELECT
    toStartOfDay(date),
    count() AS count
FROM pypi
WHERE (project = 'typing-extensions') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY date
ORDER BY date ASC

完整的结果、查询和观察结果可以在这里找到。

仅热

结果摘要

聚类对于 Snowflake 的实时分析性能至关重要，非聚类性能的平均响应时间超过 7 秒。
对于具有可比资源的集群，ClickHouse 的平均性能至少是 Snowflake 的 3 倍，第 95 和 99 百分位的性能至少是 Snowflake 的 2 倍。
即使使用 177 个 vCPU 的 ClickHouse 性能也优于使用 1024 个 vCPU 的 4X-LARGE Snowflake 仓库。这表明我们的特定工作负载无法从进一步的并行化中获益，正如 Snowflake 所述。

此查询旨在测试多系列折线图（按聚类/主键）的渲染和过滤，显示项目随时间的下载量。查询按过去 90 天的每天聚合下载量，按 Python 次要版本（例如 3.6）分组，并按项目过滤。然后将更窄的时间过滤器应用于随机时间范围（两个数据库使用相同的随机值）以模拟用户向下钻取。默认情况下，这使用 100 个最受欢迎的项目，总共 200 个查询。请注意，这里我们仍然按排序/聚类键中的列进行过滤，但按任意低基数列进行聚合。

SELECT
    date AS day,
    concat(splitByChar('.', python)[1], '.', splitByChar('.', python)[2]) AS major,
    count() AS count
FROM pypi
WHERE (python != '') AND (project = 'boto3') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY
    day,
    major
ORDER BY
    day ASC,
    major ASC

完整的结果、查询和观察结果可以在这里找到。

在这些测试中，我们对 Snowflake 使用了 to_date(timestamp), project 聚类键。在考虑压缩、冷热性能以及初始查询和向下钻取查询的响应时间时，此键表现良好。

对于冷热查询，ClickHouse 的速度至少是 Snowflake 的 2 倍。

此查询测试多系列折线图的渲染和过滤，显示项目随时间的系统。在这种情况下，虽然我们按排序和聚类配置中的列进行过滤，但我们按不同的列进行聚合。此列类似于之前的测试，但 system 列的基数要高得多。此测试首先按过去 90 天的每天聚合下载量，按系统分组，并按项目过滤。system 列较高的基数要求我们按每个项目的 top 10 值进行过滤，以避免产生过多结果。这是通过获取项目 top 10 系统的子查询实现的，并且在为高基数列呈现多系列折线图时是一种现实的方法。然后将更窄的时间过滤器应用于随机时间范围（两个数据库使用相同的随机值）。

SELECT
    date AS day,
    system.name AS system,
    count() AS count
FROM pypi
WHERE (project = 'boto3') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90))) AND (system IN (
    -- sub query reading top 10 systems for the project
    SELECT system.name AS system
    FROM pypi
    WHERE (system != '') AND (project = 'boto3')
    GROUP BY system
    ORDER BY count() DESC
    LIMIT 10
))
GROUP BY
    day,
    system
ORDER BY
    day ASC,
    count DESC

此处的子查询允许我们比较投影及其在 Snowflake 中的等效功能：物化视图。

完整的结果、查询和观察结果可以在这里找到。

仅热

对于此查询，ClickHouse 在所有指标上的速度至少是 Snowflake 的 2 倍。

ClickHouse 在冷查询上的性能也优于 Snowflake，平均速度至少快 1.5 倍。

ClickHouse 在冷查询的所有指标（除了最大时间）上的性能也优于 Snowflake，平均速度快 1.7 倍。结果在这里。

如上所述，识别项目 top 系统的子查询是使用 ClickHouse 中的投影和 Snowflake 中的物化视图（带聚类）进行优化的理想候选对象。

对于 ClickHouse，此优化仅将平均值提高了 10%，但对第 95 和 99 百分位数的影响很大，分别将其降低了 15% 和 20%。虽然 Snowflake 在所有指标上的性能提高了大约 50%，但 ClickHouse 仍然快约 1.5 倍。

在 Snowflake 中部署物化视图的用户应该知道，它们可能会导致额外的大量成本。除了需要企业计划（这会将每个积分的成本提高到 3 美元）之外，它们还需要后台服务进行维护。这些成本无法预测，需要进行实验。ClickHouse Cloud 不会单独对投影或物化视图收费，尽管用户应该测试其对插入性能的影响，这将取决于使用的查询。

此查询模拟了渲染和过滤饼图以显示项目文件类型的过程。在针对特定项目的过去 90 天内按文件类型聚合后，会将更窄的时间过滤器应用于随机时间范围。与之前的查询不同，此时间过滤器四舍五入到天粒度，以便我们可以利用 ClickHouse 和 Snowflake 中的物化视图进行父查询，即我们可以按天而不是按秒进行分组（这将等同于主表）。

SELECT
    file.type,
    count() AS c
FROM pypi
WHERE (project = 'boto3') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY file.type
ORDER BY c DESC
LIMIT 10

完整的查询结果和观察结果可以在此处找到。

ClickHouse 在热查询和冷查询方面至少快 2 倍。ClickHouse 和 Snowflake 的各自热查询速度也大约是冷查询的两倍。这两个系统都受益于时间过滤器四舍五入到最近的一天，平均性能优于之前的测试。

由于我们的钻取查询四舍五入到最近的一天，因此这些查询可以轻松转换为两种技术中的物化视图。虽然这些在 Snowflake 和 ClickHouse 中不是等效的功能，但它们都可以用于存储数据的汇总版本，这些版本将在插入时更新。有关应用此优化的完整详细信息，请参阅此处。

物化视图对此查询的性能有相当大的影响。

在 ClickHouse 中，物化视图将冷查询的性能提高了 2 倍，将热查询的性能提高了 4 倍以上——即使是高百分位数也因此在几毫秒内运行。相反，Snowflake 的性能在冷查询和热查询方面都有类似的提升——2 倍到 2 倍。这导致 ClickHouse 和 Snowflake 之间的查询性能差距更大，前者至少快 3 倍。

此查询模拟构建饼图的过程，其中使用非主键 (distro.name) 执行过滤。它对项目进行聚合，计算过去 90 天的下载次数，并对 distro.name 应用过滤器。为此，我们使用前 25 个发行版。对于每个发行版，我们都会发出一个后续查询，其中应用于随机时间范围的过滤器（两个数据库都相同）。

这里的重点是在按非聚类或有序列过滤时的性能。这不是完全的线性扫描，因为我们仍在按日期/时间戳过滤，但我们预计性能会慢得多。因此，这些查询将受益于在集群中的所有节点上分布计算。在 Snowflake 中，这是默认执行的。在 ClickHouse Cloud 中，可以通过使用并行副本实现相同的效果。此功能允许聚合查询的工作分散到集群中的所有节点，从同一分片读取数据。虽然此功能尚处于实验阶段，但已用于 ClickHouse Cloud 中的一些工作负载，预计很快就会普遍可用。

SELECT
    project,
    count() AS c
FROM pypi
WHERE (distro.name = 'Ubuntu') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY project
ORDER BY c DESC
LIMIT 10

完整的查询结果和观察结果可以在此处找到。

下面，我们展示了使用原始 708GB 服务和 project, date, timestamp 排序键启用 ClickHouse 并行副本带来的性能优势。此服务包含总共 177 个 vCPU，分布在 3 个 vCPU 上。

在热查询和冷查询的情况下，ClickHouse Cloud 查询时间使用并行副本后大约快 3 倍。这是预期的，因为所有三个节点都用于聚合。这表明并行副本对于需要扫描更多数据的查询非常强大。

在我们之前的查询中，日期和时间戳列分别是 ClickHouse 排序键中的第 2 个和第 3 个条目（项目为第 1 个）——与 Snowflake 不同，在 Snowflake 中，将日期放在第一位是有益的。在此工作负载中，我们没有项目过滤器。因此，我们使用 ClickHouse 中的 date, timestamp 排序键优化此工作负载，以与 Snowflake 保持一致。

ClickHouse 和 Snowflake 的结果

对于 ClickHouse，使用最大的 1024GB 服务（256 个 vCPU）（与 Snowflake 2X-LARGE 仓库的 vCPU 数量大致相同）可以获得最佳性能。

对于这些查询，Snowflake 快大约 30%。这可以归因于并行副本功能的实验性，它正在积极开发以提高性能。但是，在撰写本文时，Snowflake 在可以分布到许多节点并需要扫描大量数据的查询方面表现良好。

此查询测试了渲染和过滤饼图以显示随时间推移的子项目的过程。子项目是指与核心技术相关的项目，例如 mysql。这些通过使用 project ILIKE %<term>% 识别，其中 <term> 从列表中选择。此列表通过获取名称中包含 - 的名称的前 20 个前缀来识别。例如

SELECT splitByChar('-', project)[1] as base 
from pypi 
GROUP BY base 
ORDER BY count() DESC 
LIMIT 20

此测试聚合过去 90 天的子项目，按下载次数排序并过滤到项目术语。然后将更窄的时间过滤器应用于随机时间范围，模拟用户查看某个时间段内某个术语的前几个子项目，然后钻取到特定时间范围。

此查询虽然在项目列上进行过滤，但由于使用了 LIKE 运算符（例如 `project LIKE '%clickhouse%'）而无法充分利用主键。ClickHouse 查询示例

SELECT
    project,
    count() AS c
FROM pypi
WHERE (project LIKE '%google%') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY project
ORDER BY c DESC
LIMIT 10

这为利用 Snowflake 的搜索优化服务提供了机会，该服务可用于改进 LIKE 查询。我们将此与 ClickHouse 的各种辅助索引进行对比，这些索引可用于加速此类查询。这些工作作为跳过索引，无需读取实际列即可过滤数据。更具体地说，为了说明在这种情况下此功能，我们对项目列使用 n 元组布隆过滤器索引。

完整的查询结果和观察结果可以在此处找到。

我们的测试表明，布隆过滤器仅为我们的 ClickHouse 总存储大小增加了 81.75 MiB（已压缩）。即使未压缩，开销也最小，为 7.61 GiB。

在没有布隆过滤器的情况下，Snowflake 和 ClickHouse 在 LIKE 查询方面的性能相似——Snowflake 在第 95 个和第 99 个百分位数的性能甚至超过 ClickHouse 高达 30%。

ClickHouse 布隆过滤器将平均性能提高了近 10 倍，并将热查询和冷查询的较高百分位数提高了至少 2 倍。

布隆过滤器导致 ClickHouse 在所有指标上都轻松胜过 Snowflake，性能至少提高了 1.5 倍，平均情况下提高了 9 倍。布隆过滤器除了存储空间略有增加外，不会产生任何额外费用。

搜索优化服务显着提高了 Snowflake 的性能。虽然在使用布隆过滤器时，热查询的平均速度仍然低于 ClickHouse，但它在冷查询和第 99 个百分位数方面速度更快。但是，正如我们在成本分析中指出的那样，这会带来巨大的成本，使其几乎无法使用。

对于之前的测试，Snowflake 和 ClickHouse 中的查询缓存已被禁用。这提供了对实时分析用例中查询性能的更现实的指示，在这些用例中，查询要么高度可变（因此导致缓存未命中），要么基础数据正在发生变化（从而使缓存失效）。尽管如此，我们还是评估了各自查询缓存对我们初始“每日下载量”查询性能的影响。

SELECT
    toStartOfDay(date),
    count() AS count
FROM pypi
WHERE (project = 'typing-extensions') AND (date >= (CAST('2023-06-23', 'Date') - toIntervalDay(90)))
GROUP BY date
ORDER BY date ASC

完整的查询结果和观察结果可以在此处找到。

结果摘要

虽然 ClickHouse 查询缓存提供了更快的平均响应时间，但 Snowflake 确实提供了更好的值分布，并且第 95 个和第 99 个值更低。我们将此归因于 ClickHouse 的缓存是每个节点的本地缓存以及查询的负载平衡。Snowflake 在此处可能受益于在其服务层拥有一个分布式缓存，独立于节点。虽然这可能会带来略高的平均响应时间，但它的性能更一致。在生产环境中，更改数据会在大多数实时分析用例中使这些缓存优势失效。
对于冷查询，ClickHouse 受益于更高的 CPU 与内存比率，性能优于 Snowflake 1.5 到 2 倍，具体取决于指标。

在本节中，我们将比较 ClickHouse Cloud 和 Snowflake 的成本。为此，我们计算了运行基准测试的成本，包括数据加载、存储和完成所有查询。此分析还重点介绍了使 Snowflake 成为实时分析的可行解决方案并与 ClickHouse Cloud 在性能方面具有竞争力的额外成本。最后，我们提供了使用我们在测试中使用的 2 个可比较的服务/仓库大小的生产服务的简单成本计算。

我们的结果表明，ClickHouse Cloud 在各个方面都比 Snowflake 更具成本效益。具体来说，

要运行我们的基准测试

数据加载：Snowflake 的数据加载成本至少比 ClickHouse Cloud 高 5 倍。
查询：Snowflake 的查询成本至少比 ClickHouse Cloud 高 7 倍，Snowflake 查询运行时间为数十秒，而 ClickHouse Cloud 查询在几秒钟或更短时间内返回结果。为了使 Snowflake 达到可比的查询性能，Snowflake 的成本比 ClickHouse Cloud 高 15 倍。

对于生产系统

在预测运行我们的基准测试查询的生产工作负载的成本时，Snowflake 的成本至少比 ClickHouse Cloud 高 3 倍。为了使 Snowflake 达到与 ClickHouse Cloud 相当的性能，Snowflake 的成本比 ClickHouse Cloud 高 5 倍，适用于这些生产工作负载。

ClickHouse 和 Snowflake 服务/仓库每小时的成本如下

Snowflake：2X-LARGE - 每小时 32 个积分。积分成本取决于层级。除非另有说明，否则我们假设标准层级（每个积分 2 美元），即每小时 64 美元。
ClickHouse：708GB，177 核 ClickHouse 服务 - 每小时 0.6888 美元/6 个 CPU，每小时 20.3196 美元。
ClickHouse：960GB，240 核 ClickHouse 服务 - 每小时 0.6888 美元/6 个 CPU，每小时 27.552 美元。

数据库	批量数据加载成本（美元）	集群成本（美元）	每月存储成本（美元）	查询基准测试成本*（美元）
Snowflake 标准版	203	900	28.73	185.9
Snowflake 企业版	304	1350	28.73	378.98
ClickHouse	41	0	42.48	25.79

* 带集群

ClickHouse Cloud 在我们的基准测试中比 Snowflake 更具成本效益

数据加载：对于我们的基准测试，Snowflake 的数据加载成本至少比 ClickHouse Cloud 高 5 倍。如果利用集群来确保查询性能与 ClickHouse 具有竞争力，则额外的成本意味着 Snowflake 的数据加载成本高出 25 倍。
查询：Snowflake 的查询成本至少比 ClickHouse Cloud 高 7 倍，Snowflake 查询运行时间为数十秒，而 ClickHouse Cloud 查询在几秒钟或更短时间内返回结果。为了使 Snowflake 达到可比的查询性能，Snowflake 的成本比 ClickHouse Cloud 高 15 倍。

我们分别为 Snowflake 和 ClickHouse 选择了 2X-LARGE 和 708GB 的仓库和服务大小。它们的核心总数相当，并在整个基准测试中使用。
对于我们的实时分析用例，我们提供全球可访问的 Python 包分析，我们假设查询很频繁。这意味着任何仓库/服务都不会闲置。
测试使用 Snowflake 的企业版功能以获得与 ClickHouse Cloud 相当的性能（物化视图或搜索优化服务），这会增加 Snowflake 的单位成本。在这种情况下，我们为 Snowflake 提供了两种替代成本——标准版和企业版。Snowflake 的企业版也会影响加载成本，因为单位成本会增加。
在计算查询基准测试的成本时，我们使用最高性能配置（考虑层级）的结果，并将运行所有查询的总时间四舍五入到最近的分钟。
在计算查询成本时，我们使用总运行时间乘以服务的每分钟成本。请注意，Snowflake 按秒收费，每次仓库启动时最少 60 秒。ClickHouse Cloud 执行每分钟计费。因此，我们不考虑仓库/服务启动和停止所需的时间。
对于 ClickHouse Cloud 数据加载，我们使用了提供最快加载时间的服务——960GB 服务，并假设用户在加载完成后会缩减其服务规模。
我们假设 Snowflake 没有产生任何云服务计算费用。如果在 Snowflake 中使用了更高级的功能，从而改变了定价层级，我们会相应地调整每信用额度价格。
在计算查询成本时，我们使用了启用集群的结果。如 查询 1：每日下载量 的结果所示，在没有启用集群的情况下，Snowflake 的响应时间无法与 ClickHouse 竞争，并且不足以满足实时分析应用程序的需求。此工作负载的平均响应时间（未应用集群键）超过 **7.7 秒**（2X-LARGE）。相比之下，当应用最佳集群键时，ClickHouse (708GB) 和 Snowflake 的响应时间分别为 0.28 秒和 0.75 秒。基于这种对比，所有后续基准测试都对 Snowflake 应用了集群。

我们假设 Snowflake 数据仓库和 ClickHouse 服务仅在数据加载期间处于活动状态，并且在数据插入后立即暂停。在 ClickHouse 的情况下，我们允许时间进行合并，以将分区减少到建议限制 3000 以下。

数据库	规格	vCPU 数量	每小时成本（美元）	数据加载时间（秒）	批量数据加载成本（美元）
Snowflake（标准版）	2X-LARGE	256	64	11410	202
Snowflake（企业版）	2X-LARGE	256	96	11410	304
ClickHouse	708GB	177	20.3196	10400（174 分钟）	59
ClickHouse	960GB	240	27.552	5391（90 分钟）	41

在我们的用例中，Snowflake 的数据加载成本是 ClickHouse Cloud 的 5 倍。

我们的数据加载方法使用了外部阶段。这不会产生任何费用。使用 Snowflake 内部阶段存储文件的用户将产生此处未包含的其他费用。

如上所述，如果没有启用集群，Snowflake 的查询性能超过 7 秒，这对于实时应用程序来说太慢了。因此，我们的测试和基准测试启用了集群以确保更具竞争力的查询性能。

在 to_date(timestamp), project 键上进行集群消耗了 450 个信用额度。如果使用标准层级，则为 900 美元，如果使用企业版功能，则为 1350 美元。在 ClickHouse Cloud 中，指定排序键（ClickHouse 中的一个可比功能）不会产生额外的成本。

如果我们将标准层级上的集群作为数据加载成本的一部分，则 Snowflake 比 ClickHouse Cloud 贵 27 倍（900 美元 + 203 美元 = 1103 美元）。这没有考虑 Snowflake 集群的持续费用，这些费用是在插入后更新数据时产生的。

Snowflake 和 ClickHouse Cloud 对在 GCP us-central-1（我们的基准测试所在区域）中存储数据收取以下费用。其他区域可能有所不同，但我们预计这在两种情况下都不会成为总成本的很大一部分。Snowflake 和 ClickHouse 都考虑了数据的压缩大小。

ClickHouse - 每压缩 TB/月 47.10 美元
Snowflake - 每压缩 TB/月 46 美元

请注意，上述 ClickHouse 存储成本包含两天的备份（每 24 小时一次）。为了在 Snowflake 中获得等效的保留期，我们假设在生产环境中将使用永久表，并设置 1 天的时间旅行。这还默认提供了七天的故障安全支持。鉴于我们的数据是不可变的且仅追加，我们预计表中的 churn 较低，并且仅为时间旅行中超出初始副本的新数据支付增量成本——我们估计这大约为每 7 天 8%。因此，我们估计 Snowflake 的乘数为 1.08。

我们假设在大多数基准测试中使用了集群/排序键。使用这些费用，我们计算了一个月的总成本。

数据库	ORDER BY/CLUSTER BY	总大小（TB）	每 TB 成本（美元）	备份乘数	每月成本（美元）
Snowflake	(to_date(timestamp), project)	1.33	46*	1.08（用于时间旅行）	$66.07
ClickHouse	(project, date, timestamp)	0.902	47.10	1	$42.48

*按需定价

上述成本计算表明，Snowflake 的存储成本高出 1.5 倍。但是，这假设 Snowflake 使用按需存储定价。如果预购存储，则每 TB 价格降至 20 美元。假设用户能够利用这一点，则存储的总成本估计为 28.73 美元。

估算 Snowflake 的成本很复杂。Snowflake 一些最快的查询性能依赖于非标准功能的使用，例如物化视图和搜索优化服务，这些功能仅在企业版层级中可用。这会将每信用额度成本提高到 3 美元。这些服务还会产生额外的费用，例如物化视图会产生后台维护成本。 Snowflake 提供了计算这些成本的方法，例如物化视图。

为了估算查询成本，我们使用了被识别为每种查询类型最佳性能的配置，假设 Snowflake 使用 2X-LARGE 数据仓库，ClickHouse 使用 708GB 服务。

因此，对于 Snowflake，我们计算了两种定价——企业版和标准版。对于所有计算，我们使用最快配置的总执行时间（给定层级），并乐观地假设测试完成后数据仓库会立即暂停。对于 ClickHouse 的时间，我们四舍五入到最接近的一分钟。

我们不包括主表的初始 Snowflake 集群费用，并假设这些费用是在数据加载过程中产生的。但是，我们考虑了物化视图的集群费用。

我们忽略了启用查询缓存的结果。我们假设生产实例将受到更改和更新的影响，从而使缓存失效。在生产环境中，我们仍然建议为两个数据库都启用此功能。由于缓存结果具有可比性，因此我们预计对成本比率不会产生有意义的影响。

ClickHouse

测试	排序列	使用的功能	每小时成本（美元）	总运行时间（秒）	总成本（美元）
查询 1：每日下载量	project, date, timestamp	-	20.3196	302	$2.032
查询 2：按 Python 版本划分的每日下载量	project, date, timestamp	-	20.3196	685	$4.064
查询 3：按系统划分的每日下载量	project, date, timestamp	物化视图	20.3196	600	$3.387
查询 4：每个项目的顶级文件类型	project, date, timestamp	物化视图	20.3196	56	$0.339
查询 5：按发行版划分的顶级项目	project, date, timestamp	-	20.3196	1990	$11.232
查询 6：顶级子项目	project, date, timestamp	布隆过滤器	20.3196	819	$4.741
总计				4452	$25.79

Snowflake 标准版

测试	集群列	每信用额度成本（美元）	每小时成本（美元）	总运行时间（秒）	总成本（美元）
查询 1：每日下载量	date, project	2	64	635	$11.28
查询 2：按 Python 版本划分的每日下载量	date, project	2	64	1435	$25.51
查询 3：按系统划分的每日下载量	date, project	2	64	1624	$28.87
查询 4：每个项目的顶级文件类型	date, project	2	64	587	$10.44
查询 5：按发行版划分的顶级项目	date, project	2	64	1306	$23.22
查询 6：顶级子项目	date, project	2	64	4870	$86.58
总计				10457	$185.9

Snowflake 企业版

测试	集群列	使用的企业版功能	每信用额度成本（美元）	每小时成本（美元）	总运行时间（秒）	数据仓库成本（美元）	额外费用	总成本（美元）
查询 1：每日下载量	date, project	-	2	64	635	$11.289	-	$11.29
查询 2：按 Python 版本划分的每日下载量	date, project	-	2	64	1435	$25.5111	-	$25.51
查询 3：按系统划分的每日下载量	date, project	集群 + 物化视图	3	96	901	$24.027	物化视图 61.5 个信用额度 = 184.5 美元，集群 5.18 个信用额度 = 15.54 美元	$224.07
查询 4：每个项目的顶级文件类型	date, project	集群 + 物化视图	3	96	307	$8.187	集群 0.022 个信用额度 = 0.066 美元，未记录物化视图费用。	$8.25
查询 5：按发行版划分的顶级项目	date, project	-	2	64	1306	$23.218	-	$23.22
查询 6：顶级子项目	date, project	集群 + 搜索优化服务	3	96	684	$18.24	搜索优化费用 - 22.8 个信用额度 = 68.4 美元	$86.64
总计					5268			$378.98

在我们的基准测试中，Snowflake 的查询成本至少比 ClickHouse Cloud 贵 7 倍。为了使 Snowflake 的查询性能与 ClickHouse Cloud 相当，Snowflake 需要企业版层级的功能，这使得 Snowflake 的成本大幅增加，比 ClickHouse Cloud 贵 15 倍。

从以上可以看出，如果使用企业版功能，Snowflake 的查询成本会迅速增加。虽然它们几乎总是显著提高性能，但运行时间的节省并不总是能抵消单位成本的增加。因此，用户需要不断寻找执行每个查询最具成本效益的方法。相比之下，ClickHouse 的定价很简单——加速查询的功能没有任何额外费用。

在上述场景中，我们还假设对于不需要企业版功能的测试，仍然可以使用标准的 Snowflake 定价。这导致上述 Snowflake 结果的成本略有降低，但在生产环境中并不现实，因为即使使用一个企业版功能来加速查询，也会立即导致 Snowflake 中所有其他查询的成本增加 1.5 倍。解决这个问题需要复杂的配置和可能的数据复制。

上述基准测试成本计算虽然有助于突出 Snowflake 成本如何快速累积，但很难推断到生产场景。

为了构建一个简单的定价模型，我们做出了以下假设：

我们的数据仓库和服务将始终运行，没有空闲时间，因为它会持续摄取数据并提供实时查询。
虽然完整数据集的大小几乎是 10 倍，但我们还假设 3 个月的数据对于我们的应用程序足够了。
2X-LARGE 和 708GB 数据仓库/服务可以为我们的应用程序提供足够的延迟性能。
2X-LARGE 和 708GB 数据仓库/服务能够处理生产应用程序所需的查询并发性。
2X-LARGE 和 708GB 数据仓库/服务不会受到新增数据的显著影响。
对于 Snowflake，我们假设初始加载后集群成本不重要（对于 Snowflake 来说这是一个非常乐观的假设）。
我们可以忽略初始数据加载成本，因为数据仓库/服务将始终运行。

基于这些假设，我们的生产成本就变成了存储成本以及运行每个数据仓库和服务的时间。我们针对此场景提供了 Snowflake 的两种成本：标准版和企业版。虽然后者提供的响应时间更接近 ClickHouse Cloud，但 Snowflake 的成本乘数会增加 1.5 倍。

对于 ClickHouse，我们假设在可能的情况下使用物化视图和投影——这些不会增加任何可测量的额外成本。

最后，我们还提供了 4X-LARGE Snowflake 服务的定价。用户可能会倾向于在不使用集群的情况下使用此配置。虽然查询速度会变慢，但 Snowflake 已经证明了线性可扩展性——因此查询速度应该比不使用集群的 2X-LARGE 快 4 倍。这种性能可能是可以接受的，例如，在“每日下载量”测试中，2X-LARGE 的平均值为 7.7 秒的查询，在 4X-LARGE 上应该需要不到 2 秒的时间。

数据库	规格	每小时计算成本（美元）	每月计算成本（美元）	每月数据存储成本（美元）	每月总成本（美元）
Snowflake（标准版）	2X-LARGE	64	$46,080	$28.73	$46,108
Snowflake（企业版）	2X-LARGE	96	$69,120	$28.73	$69,148
Snowflake（标准版）	4X-LARGE	256	$184,320	$28.73	$184,348
ClickHouse	708GB	20.3196	$14,630	$42.48	$14,672

以上表明，运行生产应用程序的 Snowflake 成本比 ClickHouse Cloud 高出 3 倍多。为了使两个系统的性能相当，用户需要通过企业版层级的功能，而使用 Snowflake 的成本比 ClickHouse Cloud 高 4.7 倍。

实际上，我们预计这种差异会更大，因为上面的数字忽略了 Snowflake 的其他费用，包括：

添加新数据时的集群费用。为了简化定价，我们忽略了 Snowflake 的这些费用，但我们的基准测试成本表明它们是相当可观的。不使用集群的 4XLARGE 方式不可行，并且不太可能具有竞争力，如所示。
如果使用，则需要支付维护 Snowflake 中物化视图的费用。正如我们的基准测试成本所显示的那样，尤其是在与集群结合使用时，这些费用可能相当可观。
数据传输费用。根据所涉及的区域，Snowflake 可能会产生这些费用。ClickHouse Cloud 不收取数据传输费用。
在我们的测试中没有产生数据分段费用，因为我们使用了外部阶段，并简单地从 GCS 存储桶导入数据。Snowflake 中的内部阶段会产生费用，并且在某些情况下可能是必需的。ClickHouse Cloud 没有阶段的概念。

现实世界的场景会施加额外的限制。在对不同规格的系统进行基准测试后，应做出关于实际大小的决策。给定工作负载的参数在容量规划期间具有直接的影响。这些可能是处理某些工作负载在一段时间内的硬性限制，或者以低延迟处理一定数量的并行查询的容量。无论如何，需要在一段时间内完成一定量的工作。

下面，您可以看到如果我们利用集群的 100% 时间并一次运行一个基准测试，每天的工作量差异示例。