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

本 ClickHouse 与 Snowflake 博客系列由两部分组成，可以独立阅读。各部分如下：

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

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

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

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

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

复制此基准分析所需的信息和方法也已公开，网址为 https://github.com/ClickHouse/clickhouse_vs_snowflake。

在以下部分中，我们比较了 ClickHouse 和 Snowflake 的插入和查询性能，以及针对拟议应用程序的查询实现的压缩率。对于所有测试，我们都使用 GCE 托管的 us-central-1 实例，因为下面的测试数据集最容易导出到 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。

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

1. 随时间推移的下载量，呈现为折线图。
2. 按 Python 版本划分的随时间推移的下载量，呈现为多系列折线图。
3. 按系统（例如 Linux）划分的随时间推移的下载量，呈现为多系列条形图。
4. 项目的首要发行版/文件类型，例如 sdist 或 bdist，呈现为饼图或条形图。

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

1. 技术的相关子项目（如果存在）的总下载量，例如 ClickHouse 的 clickhouse-connect。
2. 特定发行版（例如 Ubuntu）的热门项目。

这可能看起来像以下内容：

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

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

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

• 我们没有评估 Snowflake 的多集群仓库功能。虽然不适用于我们的测试工作负载，但这对于扩展生产应用程序的吞吐量将非常宝贵。该方法具有优点，并且与通过添加节点来扩展服务的 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 上执行的（除非另有说明），Snowflake 的测试在 6 月的前 2 周进行。

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

• ClickHouse 提供的压缩率比 Snowflake 在启用集群的情况下提供的最佳压缩率高出 38%。
• 在我们的测试中，Snowflake 中的集群将压缩率提高了高达 45%。此功能似乎对于使查询性能在一定程度上与 ClickHouse 竞争至关重要，尤其是在按排序键进行筛选时。但是，由于负责对数据进行排序的后台进程，它带来了巨大的成本。
• 即使具有相当数量的 vCPU，并且忽略 Snowflake 集群数据所需的时间，ClickHouse 的数据加载速度也比 Snowflake 快 2 倍。这也假设文件大小对于 Snowflake 来说是最佳的 - 它在较小的文件上的性能似乎明显更差。
• 在实时分析用例中，查询可以利用集群/排序键的工作负载是最常见的。在这种情况下，对于热查询，ClickHouse 比具有更多 vCPU 的 Snowflake 仓库（177 对 256）快 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 文件约为 150MiB。

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

数据库	规格	节点数	每个节点内存 (GiB)	每个节点 vCPU	总 vCPU	总内存 (GiB)	插入线程	总时间 (秒)
Snowflake	2X-LARGE	32	16	8	256	512	不适用	11410
Snowflake	4X-LARGE	128	16	8	1024	2048	不适用	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) 的最佳结果，则对于相同数量的 vCPU，ClickHouse 的插入性能是 Snowflake 的 2 倍以上。

此测试的其他观察结果：

• 在节点较少但每个节点 vCPU 较多的集群（例如 708GB 配置）上，ClickHouse 完成初始插入操作的速度更快。但是，随后会花费时间将部件合并到可接受的阈值以下。虽然可以在节点上随时进行多次合并，但每个节点的总数受到限制。将我们的资源分散到更多节点（960GB 具有 8 个 30 核节点）允许进行更多并发合并，从而缩短完成时间（可以通过联系支持部门在 ClickHouse Cloud 中请求更高配置级别）。

• 为了实现最大加载性能，Snowflake 需要与 vCPU 一样多的文件。我们推测这是因为 Parquet 文件中的读取未并行化，与 ClickHouse 不同。虽然这在我们的数据集上不是问题，但这使得在其他场景中扩展插入具有挑战性。

• Snowflake 建议确保 Parquet 文件约为 150MiB。完整的 PyPi 数据集包含超过 1.5M 个文件和 19TiB，平均文件大小小得多，为 13MiB。由于我们预计 ClickHouse 不会受到文件大小的显着影响，因此我们遵循了 Snowflake 的 150MiB 建议。

  为了测试小 Parquet 文件行为的差异，我们将 69B 行 PyPi 数据集样本导入到 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 列应用 delta 编解码器来进一步改进它，尽管已证明这会对冷查询的性能产生副作用。

默认情况下，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) + delta 编解码器	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
（项目，时间戳）	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 百分位数高出 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` 列的基数较高，要求我们按每个项目的前 10 个值进行过滤，以避免结果过多。这是通过子查询实现的，该子查询获取项目的前 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 在所有指标上至少快 2 倍。

ClickHouse 在冷查询的平均值上也至少比 Snowflake 快 1.5 倍。

ClickHouse 在除冷查询的最大时间之外的所有方面也优于 Snowflake，平均值快 1.7 倍。结果在此处。

如上所述，用于识别项目的前几名的子查询是使用 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-gram 布隆过滤器索引。

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

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

在没有布隆过滤器的情况下，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 服务 - 每 6 个 CPU 每小时 0.6888 美元，每小时 20.3196 美元。
• ClickHouse：960GB，240 核 ClickHouse 服务 - 每 6 个 CPU 每小时 0.6888 美元，每小时 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 中获得等效的保留期，我们假设将在生产中为 Snowflake 使用永久表，时间旅行为 1 天。这也默认提供七天的故障安全支持。鉴于我们的数据是不可变的且仅附加的，我们预计表中的低流失率，并且仅为初始副本之外的时间旅行中的新数据支付增量成本 - 我们估计这约为每 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 仓库和 708GB ClickHouse 服务。

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

我们不包括主表的初始 Snowflake 聚簇费用，并假设这些费用作为数据加载的一部分产生。但是，我们确实考虑了物化视图的聚簇费用。

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

ClickHouse

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

Snowflake 标准版

测试	聚簇列	每个 кредита 成本（美元）	每小时成本（美元）	总运行时间（秒）	总成本（美元）
查询 1：每日下载量	日期、项目	2	64	635	$11.28
查询 2：按 Python 版本划分的每日下载量	日期、项目	2	64	1435	$25.51
查询 3：按系统划分的每日下载量	日期、项目	2	64	1624	$28.87
查询 4：每个项目的首要文件类型	日期、项目	2	64	587	$10.44
查询 5：按发行版划分的热门项目	日期、项目	2	64	1306	$23.22
查询 6：热门子项目	日期、项目	2	64	4870	$86.58
总计				10457	$185.9

Snowflake 企业版

测试	聚簇列	使用的企业版功能	每个 кредита 成本（美元）	每小时成本（美元）	总运行时间（秒）	仓库成本（美元）	额外费用	总成本（美元）
查询 1：每日下载量	日期、项目	-	2	64	635	$11.289	-	$11.29
查询 2：按 Python 版本划分的每日下载量	日期、项目	-	2	64	1435	$25.5111	-	$25.51
查询 3：按系统划分的每日下载量	日期、项目	聚簇 + 物化视图	3	96	901	$24.027	物化视图 61.5 个 кредита = 184.5 美元，聚簇 5.18 个 кредита = 15.54 美元	$224.07
查询 4：每个项目的首要文件类型	日期、项目	聚簇 + 物化视图	3	96	307	$8.187	聚簇 0.022 个 кредита = 0.066 美元，未记录物化视图费用。	$8.25
查询 5：按发行版划分的热门项目	日期、项目	-	2	64	1306	$23.218	-	$23.22
查询 6：热门子项目	日期、项目	聚簇 + 搜索优化服务	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% 的时间并一次运行一个基准测试，则每天的工作量有何不同。

数据库	规格	总基准测试时间（秒）	每天基准测试运行次数	每天计算成本	每 1000 美元基准测试运行次数
Snowflake（标准版）	2X-LARGE	10457	8.26	1536	5.37
Snowflake（企业版）	2X-LARGE	5268	16.40	2304	7.11
ClickHouse	708GB	4452	19.40	488	39.76

上文显示，在相同的计算成本下，ClickHouse 可以处理的工作量比 Snowflake 高 5.5 倍。请注意，如上所述，随着使用诸如物化视图和集群之类的查询加速功能，Snowflake 的成本会急剧增加。

这篇博文全面比较了 Snowflake 和 ClickHouse Cloud 在实时分析方面的性能，表明对于实际的应用程序，在我们的基准测试中，ClickHouse Cloud 在成本和性能方面均优于 Snowflake。

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

立即联系我们，详细了解使用 ClickHouse Cloud 进行实时分析。或者，开始使用 ClickHouse Cloud 并获得 300 美元信用额度。