Sprig 实测:一个 ScyllaDB 换掉 Postgres+ClickHouse+Redis,读延迟快 4-8 倍

主角:一家小公司扛住了多大的量

Sprig 做产品内调研(在用户完成关键动作时弹出问卷),团队不大,但数据量是实打实的平台级:

指标 规模
追踪的独立访客 **150 亿**(跨多设备)
属性(attributes) **750 亿**
事件计数器 **200 亿**
累计处理事件 **1.3 万亿**
实时处理速率 **每秒 2 万–4 万** 事件与属性

Sprig 业务与数据规模概览(原文信息图)

问题在于,每一次 SDK 调用都要先读到访客记录,再判断是否命中触发条件——整个判断必须在毫秒级完成,否则问卷就弹不出来。

原来的三件套,各自卡在哪

  • Postgres:访客数据放在一张未分区的大表上(因为要跨多列查询,建了好几个索引),每秒 3 万–5 万次请求。共享环境下,一条烂查询或一个缺失索引就能把整体拖垮。
  • ClickHouse:作为记录系统(system of record),每秒 4 万–5 万次写入、2 千–6 千次读取。团队为了压住读延迟做了极限调优:访客 ID 哈希到单分区、把 granule 大小压到标准 8200 行以下、max threads 设为 1 并改用 pread,避免线程在重查询时互相抢 CPU。
  • Redis:扛住全量工作集和绝大部分请求流量,ClickHouse 在它后面兜底。
  • 即便如此,P99 仍在 50ms 左右,访问模式切换、批任务一跑就出现周期性 brownout(短时性能塌陷)。三套系统三份运维,而运维的人手是个位数。

    ClickHouse 与 Redis 的分工与瓶颈(原文信息图)

    四条路,三条被否

    团队评估了四个方向:

    候选 结论
    **DynamoDB** 否——按 Sprig 的读写量,RCU/WCU 计价成本扛不住;团队此前还吃过写入可靠性亏
    **DataStax Astra** 否——基准测出来延迟更高、扩展行为不确定;IBM 收购带来的不确定性也是风险
    **自建 Cassandra on K8s** 否——测试里尾延迟立刻不可接受,而且等于让**两个人的团队**长期运维一个大型 Java 分布式数据库
    **ScyllaDB** ✅ 选中——低延迟扛得住 Sprig 的规模(注:自托管 K8s 版也被排除,最终落地的是 Cloud 托管版)

    被否掉的三条里,最扎心的是 Cassandra 那条:技术上并非不可行,是运维人力不允许。

    四个候选方案的取舍(原文信息图)

    迁移:双写 + 双读校验,对齐到 99.99% 才切

  • 增量写入:所有流向 ClickHouse 的数据本来就经过 Kafka,团队写了个 Kafka 连接器同时双写 ScyllaDB,两套系统并行跑。
  • 存量数据:用批量加载器灌入。
  • 冲突处理:两条写路径并行,采用 last-write-wins,以每条记录的 updated_at 字段作为权威时间戳。
  • 切换标准:搭了一层双读校验,同时从旧集群和 ScyllaDB 读同一批数据做比对,一致率跑到约 99.99% 才切流量。
  • 迁移流程:Kafka 双写 + 双读校验(原文信息图)

    结果:读延迟 4-8 倍改善

    Sprig 高级工程师 Brendan Cox 的原话:属性负载上 ScyllaDB 的读延迟约为 Redis 的 1/4,整体平均延迟约 500 微秒、P90 约 1-2 毫秒,比原 Redis 方案好 4-8 倍。

    ScyllaDB 与 Redis 的 P99 延迟对比(原文信息图)

    下一步他们准备上 Incremental Compaction(写放大更优,适合缓存读场景)和 Workload Prioritization(保证周末批任务不挤占实时读)。

    小夏点评

  • 这篇的价值不在”ScyllaDB 赢了”,而在它把否决理由写清楚了:DynamoDB 死于计价模型,Astra 死于厂商被收购,自建 Cassandra 死于两个人要养一个 Java 分布式集群——这三条对国内团队同样是硬约束。
  • 迁移方法比结果更值得抄:Kafka 双写 + 批量灌存量 + last-write-wins(以 updated_at 为权威)+ 双读校验对齐到 99.99% 才切。这是小团队做”不可逆迁移”时最稳的模板。
  • 给中国 IT 运维/开发:国内常见的”OLTP + 分析 + 缓存”三件套架构,本质是为三种负载各养一套系统和一套值班表。当一个 20k–40k/s 的负载能在单库里做到均值 500µs、P90 1-2ms,”合并到一套”就值得重新评估——但前提是先按 Sprig 的方式把双读校验跑出来,别拿”官方说快 4 倍”直接立项。
  • 参考来源

  • ScyllaDB 官方博客:How Sprig Replaced Postgres, ClickHouse & Redis with 4-8x Better Latency(2026-08-24,作者 Cynthia Dunlop)
  • 您可能还喜欢...

    发表回复

    您的邮箱地址不会被公开。 必填项已用 * 标注