m3ter 为何选择 ClickHouse Cloud

按使用量定价正变得越来越普遍，尤其是在软件即服务 (SaaS) 公司中。按使用量定价的采用已成为主流，从 2018 年占 SaaS 公司的 27% 增加到 2023 年的 61%（根据 OpenView Venture Partners）。

m3ter 致力于解决中型和大型企业自动化计费方面的重大差距，提供一项服务，将客户使用数据转化为账单明细项目，支持最复杂的基于使用量（和混合）的定价方案。

在 m3ter，我们有两类数据——“控制”平面，其中包括所有配置数据（相对较小），客户可以定义这些数据来确定如何评估其原始使用数据并将其转化为账单明细项目；以及“数据”平面，其中包含所有使用数据（规模可能非常庞大）。

下面的高层架构图显示了这一切如何在 m3ter 服务中链接在一起

处理控制平面数据相对容易——由于数据量和更新频率相对较低，标准的 OLTP 数据库可以处理这些数据。

另一方面，数据平面更成问题。客户每月可以发送数亿个使用“事件”，因此总体数据量非常大。

m3ter 为客户提供各种强大的功能

• 消除重复的使用数据
• 能够修复配置错误并使用新配置重新计算当前账单，而无需重新摄取所有使用数据
• 随时更改定价、最终客户计划（例如，从“生产”层级转移到“企业”层级）等，包括在结算期中途
• 根据客户指定的标准（例如，时间范围、使用数据类型等）删除客户错误发送的使用数据
• 频繁更新账单以显示近乎实时的使用情况和成本
• 定价实验——能够根据多个配置评估使用情况，以确定拟议的价格变更的影响

许多处理大量数据的服务会在接收数据时预先聚合数据，以便稍后对数据进行的查询实际上是针对较小的数据集进行操作。但是，预聚合与上述某些功能不兼容。例如，为了预聚合数据，您需要确切地知道在运行任何查询之前需要如何聚合数据——这可能会阻止更改配置和重新计算账单，而无需重新摄取使用数据（以便可以使用新配置再次预聚合）。在某些情况下，这对于客户来说是困难的甚至是不可能的（例如，如果原始数据没有被保留）——而在 m3ter 中，这始终是可能的，因为我们保留了未聚合的数据。当进行“回顾性”配置更改时，客户无需重新发送使用数据。

此外，在 m3ter，我们不希望我们的工程师花费大量时间在“无差别的繁重工作”上——在可能的情况下，我们更喜欢使用托管服务，这延伸到我们的数据库和存储解决方案。

这些功能导致了我们数据平面存储解决方案的以下关键要求

• 使用数据不能预聚合，即必须以未聚合的形式存储
• 使用各种“配置”（即查询，对于给定的客户数据集，这些查询可能随时更改）频繁、快速地聚合大量数据
• 根据客户指定的标准删除使用数据
• 重复数据消除
• 托管数据库服务

我们将在本文的大部分篇幅中探讨我们为何选择 ClickHouse Cloud。性能比我们之前的解决方案提供的性能高出几个数量级，而且我们实现这一目标的成本也显著降低！

与我们之前的解决方案相比，我们目前实现了

• 平均每秒摄取行数增加 10 倍
• 平均每秒查询次数增加 17 倍（峰值时为 27 倍）

ClickHouse 还实现了令人印象深刻的总体压缩比 11.4 倍（即，每 1 TiB “原始”数据压缩到磁盘上约 90 GiB），这明显优于我们之前的解决方案（大概是由于更好的算法与列式存储相结合）。

尽管工作负载增加，但查询平均在 100 毫秒内运行完毕。为了说明这一点，我们的 PoC 测试表明，对于一项特定的测试，ClickHouse Cloud 的平均查询持续时间为 144 毫秒，而 RedShift（规模调整为运行成本与 ClickHouse 部署大致相同）则明显较慢，为 3927 毫秒，相差约 27 倍。我们仍然认为 RedShift 是一个很好的工具，但它不太适合我们的特定工作负载。

这一切都是在平均资源使用量为 10 个 vCPU 和 25 GiB 内存的情况下实现的。我们可以合理地预期，在开始触及“现成”部署的限制之前，可以扩展到当前工作负载的 10-100 倍。

就总体成本节省而言，主要数据是，与我们之前的评级数据库解决方案相比，我们目前节省了约 85% 的成本。

由于 ClickHouse Cloud 是一种托管服务，我们还节省了额外的工程资源成本。例如，由于我们的 ClickHouse Cloud 部署主要将数据存储在 S3 中（提供近乎无限、相对便宜的存储），我们不再需要花费时间来调整数据库可用的磁盘空间量。

现在，我们将详细探讨我们如何最终选择 ClickHouse Cloud 而不是其他可能的解决方案。

为了选择最适合我们需求的数据库，我们对几种数据库进行了概念验证 (PoC) 项目，涵盖了一系列技术和功能。我们根据一组标准对每个数据库进行了评估

• 轻松存储大量数据的能力
• 维持高数据摄取率
• 消除重复数据
• 数据摄取的简易性
• 针对大量数据进行高并发、频繁查询的查询性能
• 支持批量数据导出
• 支持数据删除
• 监控高层和低层性能的能力
• 易于扩展且零停机
• 高可用性 (HA) 和灾难恢复 (DR)
• 解决方案的总体成本
• 其他杂项标准

对于某些标准，我们定义了初始目标，以帮助我们进行公正和无偏见的比较。我们定义的目标是最低目标——如果数据库未能达到这些最低目标，则将其排除在可能的解决方案之外。在可能的情况下，我们进一步推动数据库，进行破坏性负载测试，以了解我们可以期望达到的负载类型。

我们确定的用于 PoC 测试的数据库是

• ClickHouse Cloud
• Snowflake
• Firebolt
• Amazon Redshift
• Amazon Aurora (Postgres)

请注意，我们包含 Aurora 是为了涵盖所有方面。我们并没有特别期望基于行的 OLTP 数据库在我们将要运行的特定类型的工作负载（分析性质更强）方面表现出色。从这个意义上说，将其他选项与 Aurora 进行比较感觉不公平，因为它针对的是不同的用例，但我们将其包含在内是为了让自己确信我们已经涵盖了一系列数据库选择和技术。

在测试这些解决方案时，我们尝试了各种表模式，并试图利用它们可能提供的任何独特功能来提高性能。重要的是要注意，在许多情况下，都存在权衡——例如，在表上添加索引可能会加快查询速度，但会降低摄取速度。同样，扩展解决方案以提供更多的硬件能力可以带来更好的性能，但成本更高。

在所有情况下，我们都使用了一组固定的数据和查询，代表了我们的真实工作负载。所有解决方案的源数据集都是相同的。查询在解决方案之间略有不同，这是由于可用的不同模式和功能造成的，但在所有情况下，我们始终查询相同的结果集以进行公平比较。

让我们来看看我们发现的一些亮点（和缺点）。

以上所有数据库都能够存储大量数据，这并不令人意外，因为它们都（Aurora 除外）主要设计用于处理 OLAP 工作负载。Aurora 和 Timescale 等服务在此标准上的得分较低，因为数据存储在传统磁盘（例如 SSD）上。随着存储数据量的增加，我们将不得不扩展服务以提供更多磁盘空间。相比之下，ClickHouse Cloud 等服务得分更高，因为它们没有这种运营开销——数据会自动卸载到 S3 等存储中，只有热数据集存储在本地磁盘上，这意味着我们不必担心磁盘空间不足。

我们还发现，某些解决方案中的数据压缩受到限制——基于行的解决方案没有表现出与其他一些候选方案相同的压缩比。基于列的存储往往能实现更好的压缩比，因为您一次压缩一列数据（而不是行）。由于给定列中的所有数据通常相似，因此可以实现更高的压缩比。

对于我们测试的配置，所有候选方案都可以满足所需的指标。但是，我们注意到，随着表的增长，Aurora 开始减速，内部维护操作开始消耗更多的时间和资源。我们使用我们测试的 Aurora 配置实现了高达约 10 万行/秒的速度，对于基于行的 OLTP 数据库来说，这当然还不错。但是，与其他一些解决方案相比，这相形见绌，所有其他解决方案都能够实现更高的速率（例如 10 倍）。这里的另一个担忧是，Aurora 只能通过扩展单个“写入器”节点来扩展（用于写入），而其他解决方案可以水平扩展，并且工作负载可以潜在地分布在多个节点上，这将允许更高的上限。

我们确实发现，将大数据批次摄取到 Firebolt 中所花费的时间比我们最初预期的要长，从某种意义上说，摄取“查询”花费了相当长的时间才向客户端返回 OK 响应。我们被告知这是 Firebolt 在摄取请求被视为完成之前执行的各种数据完整性检查。（还值得注意的是，我们被告知这将随着积极的开发工作而改进——因此，在撰写本文时，这完全有可能已经得到改进）。虽然这没有影响总体吞吐量，但它确实影响了数据实际可用于查询的速度，因此是我们略微担心的问题。

值得一提的是，在我们评估这些服务时，Snowflake 和 Redshift 在数据摄取方面提供了最好的生态系统。例如，Snowflake 提供了 Snowpipes，允许从数据流进行持续摄取，Redshift 提供了与 Kinesis 流的类似集成。当时，ClickHouse Cloud 没有同等的产品，因此我们不得不编写自己的 ETL 和摄取管道。此后，随着 Clickpipes 的发布，情况发生了变化——但是，由于这些在我们执行 PoC 时不可用，因此 Snowflake 在这方面得分最高。

当客户发送数据时，他们可以为每个测量值分配一个唯一 ID (UID)。这使我们能够轻松处理诸如网络错误之类的场景，在这些场景中，客户不确定他们发送的测量值是否被 m3ter 接收。通过为每条数据分配一个 UID，可以重新发送数据，确信 m3ter 将对数据进行去重，并且使用量不会在账单上重复计算。

传统的 OLTP 数据库（如 Aurora）擅长此任务——UID 字段上的简单唯一索引可确保不会将重复项插入数据库中。其他数据库（如 ClickHouse Cloud、Snowflake、Firebolt 和 Redshift）对此的支持有限，这是因为它们存储和索引数据的方式。通常，可以使用一些功能来帮助解决此问题——例如，当 ClickHouse Cloud 的 内部“合并”后台进程运行时，它可以删除重复行。但是，在此发生之前（并且 无法准确保证何时会发生，因为它是一个内部进程），重复项存在于数据库中，并且会影响查询结果。（请注意，在 ClickHouse 中，可以在查询中包含 FINAL 关键字以确保在查询时进行去重，但这会以牺牲查询性能为代价）。对于这些系统，我们需要在将数据插入数据库之前实现我们自己的行级去重流程。这增加了任何潜在解决方案的复杂性和工程开销，这意味着与 Aurora 相比，这些系统的得分较低。

这相当复杂。正如预期的那样，基于行的解决方案通常性能较差，IO 是主要瓶颈，因为即使不是查询所需的所有数据列，也需要从磁盘读取整行数据。

ClickHouse Cloud 和 Snowflake 等解决方案在此方面表现良好——我们轻松达到了目标，持续速率为每秒数百个查询。

Redshift 更加困难——尽管我们确实达到了目标，但我们无法高度确信我们将来可以继续扩展它。Redshift 更适合传统的 OLAP 查询——也就是说，少量非常复杂的查询。我们的测试涉及大量简单查询（我所说的“简单”是指相对于我在某些 OLAP 工作负载中见过的庞然大物而言）。我们还担心 Redshift 在后台使用的 vacuuming 过程——当大量资源花费在此过程上时，这可能会导致服务吞吐量偶尔出现“小故障”。虽然所有成熟的数据库都有一些类似或等效的后台进程在运行，但我们没有遇到 ClickHouse Cloud 或 Snowflake 由此造成的任何性能下降。

Firebolt 同样达到了查询吞吐量目标，但我们发现，虽然水平扩展服务确实提高了我们可以实现的吞吐量，但它的扩展性不如某些托管服务。虽然这意味着我们可以随着工作负载的增长而继续扩展，但我们为额外硬件支付的费用会看到收益递减。（公平地说，没有哪个服务可以完美扩展，所有服务都会表现出一定的收益递减——但在这一特定方面，某些服务明显优于其他服务）。

可以从正在测试的所有候选方案中导出数据（例如，作为查询结果）。但是，某些服务使此过程比其他服务更容易、更高效。例如，ClickHouse Cloud 提供了 S3 表函数，允许将查询结果直接导出到 S3 中的文件。其他一些选项将需要我们编写一些导出代码才能实现相同的结果，这将意味着更高的维护和运营成本（在人力资源方面）。

所有数据库都支持数据删除，尽管某些数据库的性能优于其他数据库。

Aurora 作为传统的 OLTP 数据库，数据删除处理得非常好，得分很高。包括 ClickHouse Cloud 在内的解决方案确实支持数据删除，但由于这些数据库的列式存储性质，删除操作可能比基于行的数据库重一些。

此外，诸如聚合视图之类的某些功能仅通过插入触发器更新，这意味着如果我们确实想使用视图预聚合数据以提高性能，则对于每次数据删除，都需要手动更新视图。实际上，由于我们不打算使用这些预聚合视图，因此这对我们来说不是问题，因此不会影响我们的评分，但是值得牢记，以防我们将来确实发现这些功能的用例。

所有候选方案都提供了一些开箱即用的监控。Firebolt（在测试时）在这方面有些不足，从 UI 中无法明显观察到 CPU、内存或磁盘使用情况。自那时以来，这很可能已经改变，也可能可以通过 SQL 查询或类似方式获得此数据——但是，这意味着我们需要做更多的工作才能实现。

其他服务通常提供更好的开箱即用监控工具，其中一些服务允许按查询级别获取详细指标。ClickHouse Cloud 是此处的总体赢家，它易于使用，图表显示了高级指标，例如 CPU、内存等，以及它们的 query_log 表跟踪单个查询级别的资源使用情况，从而可以进行更详细的分析和调试。

ClickHouse 监控示例

许多测试的服务都提供基于工作负载的自动扩展。这对我们很有吸引力，因为我们不希望我们的工程师花费时间监控性能并定期扩展和缩减服务。

实际上，可悲的是，我们发现这些服务都不完全适合我们的用例，并且在扩展（或扩展）到更大的实例时，通常会有点过于敏感。例如，通常运行良好但包含偶尔“大”查询的工作负载可能会触发服务认为它需要更多资源，而实际上，我们只是可以接受 1% 的查询花费稍长的时间。我们认为这是我们相当独特的工作负载的结果，自动扩展可能对许多人来说都非常有效。只是对我们来说，很遗憾不是这样。幸运的是，ClickHouse Cloud 提供了 扩展 API，这意味着我们可以根据我们自己的扩展算法和要求轻松扩展服务。

某些服务（如 Aurora）确实提供“无服务器”选项，您需要根据查询的数量/持续时间而不是部署的实例大小付费。但是，正如这些产品通常的情况一样，当运行较重的工作负载时，这会很快变得非常昂贵，并且更适合较小或峰值较多的工作负载。我们的工作负载既庞大又连续，因此在我们的特定情况下，无服务器产品无法提供最佳的性价比，因此被排除在外。

对于此标准，服务之间的选择相对较少。几乎所有候选方案都提供了良好的高可用性，实例部署为节点集群，分布在多个 AWS 可用区中。

在我们的测试时，Redshift 不提供多可用区配置，尽管此功能在预览版中可用。鉴于我们希望尽快迁移，并且多可用区在当时未正式发布，因此 Redshift 在此方面的得分较低。

同样，灾难恢复由所有候选系统提供的备份策略涵盖，尽管某些服务（如 ClickHouse Cloud，它将所有数据存储在 S3 中（并将热数据复制到快速本地磁盘））具有额外的优势，即 S3 本身开箱即用地提供高可靠性和冗余，因此遇到灾难恢复场景的可能性降低。

平衡相互竞争的需求（例如，摄取速率与查询性能）意味着很难评估哪个服务真正提供了最佳的“性价比”。这就是我们的初始目标再次证明其价值的地方。我们以固定的目标摄取速率和查询吞吐量测试了每项服务，并将每项服务缩减到可以达到这些目标的最小配置。

在评估此标准时，我们必须考虑计算成本和存储成本。我们计算了固定数据集的存储成本，该数据集代表了我们需要在生产环境中存储的数据量。

ClickHouse Cloud 是此处的明显赢家，当扩展到达到我们目标所需的最小配置时，就原始性能与每美元支出而言，它明显更便宜。

除了以上内容，我们还考虑了诸如服务可以部署到哪些区域、通过基础设施即代码 (IaC) 轻松部署、SOC 认证、数据加密、数据库模式演变等标准。正如预期的那样，不同的数据库在这些标准上的得分不同，但没有一个数据库得分太差，以至于我们不愿意接受任何额外的努力，如果它最终被证明是最佳解决方案。

例如，像 Aurora 和 Redshift 这样的 AWS 服务在它们支持的区域数量以及对 IaC（例如 CloudFormation）的支持等领域名列前茅，但其他服务提供了足够的支持（无论是自动部署，还是管理 API，以便我们可以自己实现自动化，还是非常简单的手动部署过程），这对我们来说是可以接受的。

综合考虑所有因素，我们发现，对于我们的特定工作负载，AWS 上的 ClickHouse Cloud 提供了最佳的性能和最佳的性价比。对于更主观的标准（每个服务中实现的差异使得直接比较变得困难），例如监控、高可用性/灾难恢复、扩展等，ClickHouse Cloud 的得分也很高。

我们认为这是一个我们可以轻松地日常使用的数据库服务。云产品的 UI 易于使用，用户管理允许实施合理的控制，以便各种用户/服务只能执行所需的操作（最小权限原则）。

此外，ClickHouse 是一个成熟的数据库，被许多客户使用，这让我们相信我们不太可能遇到任何不受欢迎的意外。在我们的 PoC 期间，我们从他们那里获得的支持和建议是一流的，这让我们真正相信，如果我们确实遇到任何问题，我们不会被留下独自解决问题。

在将 ClickHouse Cloud 实施为我们使用数据的主要数据库后，我们对我们的选择感到非常满意。我们没有遇到任何特别的痛点，并且由于可用的详细监控，调查性能（例如，对于新功能）变得很容易。query_log 表中的每个查询指标几乎是无价的，因为我们可以使用标准 SQL 查询该数据，就像查询任何其他表中的数据一样。

ClickHouse Cloud 非常适合“实时分析”，这正是我们在 m3ter 中使用数据工作负载所需要的。我们确实为不同的用例使用了各种其他数据库，因此这不是“一刀切”的情况。与大多数复杂服务一样，混合使用数据库和技术，并为每个不同的用例选择“同类最佳”，通常会产生最佳结果。在我们的例子中，我们的概念验证测试确定 ClickHouse Cloud 是我们评级引擎当前“同类最佳”的产品。