跳到主要内容
跳到主要内容

成功案例

本指南是社区交流活动中汇总实践经验的一部分。若想获取更多真实场景下的解决方案与洞见，你可以按具体问题浏览。 需要一些在生产环境中调试问题的技巧？请查看社区指南：Debugging Insights。

这些案例展示了各家公司如何在自身场景中通过使用 ClickHouse 获得成功，有的甚至挑战了传统的数据库分类方式，证明有时看似“错误”的工具，反而会成为最合适的解决方案。

将 ClickHouse 用作限流器​

当 Craigslist 需要添加一级（tier-one）限流来保护用户时，他们遇到了每个工程团队都会面对的相同抉择——遵循常规做法使用 Redis，还是尝试不同的方案。Brad Lhotsky 在 Craigslist 工作时，很清楚 Redis 是标准选择——几乎所有限流教程和线上示例都在用 Redis，这是有充分理由的。它为限流操作提供了丰富的原语、成熟的模式以及经过验证的可靠实践。但 Craigslist 使用 Redis 的体验与教材中的示例并不一致。“我们使用 Redis 的经历并不像你在电影里看到的那样……我们遇到了很多奇怪的运维问题，比如重启 Redis 集群中的某个节点时，前端会出现延迟尖峰。” 对于一个追求简单易维护的小团队来说，这些运维上的麻烦正在变成真正的问题。

因此，当 Brad 接到限流需求时，他采用了不同的思路：“我问老板，‘你觉得这个想法怎么样？也许我可以试试用 ClickHouse 来做？’” 这个想法并不常规——用一个分析型数据库来解决通常由缓存层承担的问题——但它满足了他们的核心要求：故障时保持放行（fail open）、不引入额外延迟，并且对小团队来说在维护上是安全可控的。该方案利用了他们已有的基础设施——访问日志已经通过 Kafka 写入 ClickHouse。团队无需维护单独的 Redis 集群，而是可以直接从访问日志数据中分析请求模式，并把限流规则注入到现有的 ACL API 中。这种方法相比 Redis 带来了略高的延迟，后者 “有点像作弊，因为它是通过预先把那份数据集加载好”，而不是执行实时聚合查询，但这些查询依然能在 100 毫秒以内完成。

关键结果：

  • 相比 Redis 基础设施有显著改进
  • 内置 TTL 实现自动清理，消除了维护开销
  • SQL 的灵活性支持超出简单计数器的复杂限流规则
  • 复用现有数据管道，无需额外建设独立基础设施

用于客户分析的 ClickHouse​

当 ServiceNow 需要升级其移动分析平台时，他们面临一个简单的问题：“为什么要替换一个运转良好的系统？” 来自 ServiceNow 的 Amir Vaza 很清楚他们现有的系统很可靠，但客户需求已经在超出现有系统的处理能力范围。“驱动我们替换一个现有可靠模型的动力，其实来自产品层面的考量，” Amir 解释道。ServiceNow 将移动分析作为其面向 Web、移动端和聊天机器人的整体解决方案的一部分提供，但客户希望获得超越预聚合数据的分析灵活性。

他们之前的系统使用了大约 30 张不同的表来存储预聚合数据，并按固定维度进行划分：应用、应用版本和平台。对于自定义属性——客户可以发送的键值对——他们为每一组创建了单独的计数器。这种方法提供了快速的仪表盘性能，但也带来了一个重大限制。“虽然这在进行快速数值拆解时非常有用，但这种限制会导致大量分析上下文的丢失，” Amir 指出。客户无法执行复杂的客户旅程分析，也无法提出类似“有多少会话是以搜索词 ‘research RSA token’ 开始的”这种问题，然后分析这些用户接下来的行为。预聚合的数据结构破坏了多步分析所需的顺序上下文，而且每增加一个新的分析维度，都需要工程团队进行预聚合和存储的工作。

因此，当这些限制变得非常明显时，ServiceNow 迁移到了 ClickHouse，彻底消除了这些预计算约束。他们不再预先计算每一个变量，而是将元数据拆分为数据点，并将所有内容直接插入 ClickHouse。他们使用了 ClickHouse 的 async insert queue（异步插入队列），Amir 称其为*“真正令人惊叹”*，来高效处理数据摄取。这种方法意味着客户现在可以自行创建细分，将数据按任意维度自由切分，并执行以前无法实现的复杂客户旅程分析。

关键结果：

  • 在无需预计算的情况下，实现跨任意维度的动态细分
  • 复杂的客户旅程分析成为可能
  • 客户可以自行创建细分并自由切分数据
  • 新分析需求不再形成工程瓶颈

视频资源​

这些案例展示了，质疑关于数据库的传统观念如何能够催生突破性的解决方案，从而重新定义分析型数据库的可能性。