◈ DB 选型参考
← 返回首页

Apache Cassandra / ScyllaDB

KV · 宽列 · 文档 #宽列 #最终一致性 #可调一致性 #无主架构 #水平扩展 #高写入 #CQL #跨数据中心

宽列分布式 NoSQL 的鼻祖与它的 C++ 重写：为"写密集、永远在线、水平扩展"而生的最终一致性存储。Cassandra 是生态与许可证中立性的代表；ScyllaDB 是单节点性能与尾延迟的代表，代价是 2025 年起的 source-available 许可证与更小的社区。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项Apache CassandraScyllaDB
厂商 / 组织Apache 软件基金会（社区驱动；商业生态曾由 DataStax 主导）ScyllaDB Inc.（美国加州 Sunnyvale）
国家美国（ASF）美国
首次发布2008（Facebook 开源）2015（AGPL 开源）
许可证Apache 2.0（纯开源）2025.1 起统一为 source-available；6.2 是最后一个 AGPL 版本
托管服务生态托管：DataStax Astra DB（2025-05 被 IBM 收购，现归属 watsonx.data）、AWS Keyspaces、Azure Managed Instance、Google CloudScyllaDB Cloud / X Cloud（DBaaS）
主类型宽列（wide-column）分布式 NoSQL宽列（wide-column）分布式 NoSQL
兼具类型向量搜索（5.0 起原生）向量搜索（2026 年加入，Cloud 优先）、DynamoDB API（Alternator）
一致性模型可调一致性（最终一致打底）可调一致性（最终一致打底），与 Cassandra 语义一致
复制协议无主复制 + Gossip + hinted handoff + 反熵修复同 Cassandra 语义；拓扑变更由 Raft 驱动；数据分布自 2025.1 默认用 tablets

硬维度（47 项）

1 静态加密 / TDE 部分支持

  • Cassandra：部分支持官方文档。commitlog 可加密（transparent_data_encryption_options）；SSTable 落盘加密在开源版查证为无（该能力历史上保留给 DataStax Enterprise）；备份（nodetool snapshot）无内置加密，依赖对象存储服务端加密待验证。
    • ScyllaDB：有（官方文档/官方博客）。统一版本包含原企业版的落盘加密；Cloud 版支持数据库级加密（AES-128/256，用户表 + commitlog + batchlog + hint 均加密，支持 AWS/GCP KMS 客户主密钥）；自建版 KMS 集成细节待验证。

2 TLS / 传输加密 有

有官方文档。Cassandra：client_encryption_options（客户端↔节点）与 server_encryption_options（节点间，internode_encryption: all/dc/none）；5.0 新增 mTLS 证书认证（官方发布口径）。ScyllaDB：同等 client/server 加密选项，支持证书认证（CertificateAuthenticator，社区实测）。

3 审计 有

  • Cassandra：有（官方文档，4.0+）。audit_logging_options：按节点落文件的审计日志，类别含 QUERY/DML/DDL/DCL/AUTH/ERROR/PREPARE，支持 keyspace/用户过滤，可运行时经 nodetool 开关；堆内存与磁盘占用有界（官方口径）。
    • ScyllaDB：有（官方仓库代码/社区论坛）。audit 子系统支持输出到 syslog 或 audit.audit_log 表，类别 QUERY/DML/DDL/DCL/AUTH/ADMIN，可按 keyspace/table 选择性审计，密码脱敏；原为企业版能力，2025 年初已合并入统一代码库。

4 认证与权限 有

有官方文档。Cassandra：PasswordAuthenticator + CassandraAuthorizer，CQL GRANT/REVOKE 的 RBAC（keyspace/table 级），角色可嵌套；Kerberos/LDAP 为 DSE 企业版能力（开源版查证为无）。ScyllaDB：密码认证 + 角色权限（与 CQL 语义一致）+ LDAP/AD 集成（原企业版，现统一版本包含，官方发布口径）。

5 备份恢复 有

  • Cassandra：有官方文档 社区共识。nodetool snapshot（硬链接冻结 SSTable，秒级、无 IO 冲击但占同卷磁盘）+ 增量备份 + commitlog 归档可拼出 PITR；开源 Medusa（Spotify 起源，现由社区维护）支持全量/差异备份到 S3/GCS 并可校验；恢复为逐节点拷贝 SSTable 或 sstableloader，TB 级大集群恢复耗时以小时计社区共识。
    • ScyllaDB：有官方文档。ScyllaDB Manager 提供计划备份到 S3/GCS/Azure（sctool）；底层同样是 snapshot 机制；官方集成测试矩阵注明：恢复不支持 Authentication 与 Service Levels 的还原（官方仓库文档，选型时注意）。

6 可观测性 部分支持

  • Cassandra：部分支持官方文档 社区共识。nodetool + JMX 指标是官方链路；Prometheus/Grafana 需外部 exporter 或第三方采集器拼装，无官方内置端到端监控栈。
    • ScyllaDB：有官方文档。内置 Prometheus metrics 端点 + 官方 ScyllaDB Monitoring Grafana 仪表盘栈（含告警），另有 REST API、tracing 与轻量慢查询日志。

7 连接模型 有

有社区共识。CQL 原生二进制协议；官方多语言驱动均为 token-aware（直连负责副本的节点，避开 coordinator 跳转）；ScyllaDB 另提供 shard-aware 端口（19042） 与专用驱动，直连目标 CPU shard。连接本身轻量，无 PG 式连接数瓶颈；但 coordinator 仍是跨分区查询的汇聚点，超大应用机群仍建议经代理或驱动侧限流社区共识。

8 事务与隔离级别 无多行 ACID

无多行 ACID（官方文档，查证为无）。单行写入原子；LWT（IF NOT EXISTS / IF 条件）提供单分区 Paxos compare-and-set 线性一致；BATCH 保证同分区原子性（非隔离性），跨分区 batch 仅保证最终写入、无隔离。Cassandra 4.1+ 可切 Paxos v2（paxos_variant: v2），无竞争 LWT 从 4 RTT 降到写 2 RTT/读 1 RTT（CEP-14，社区技术文档）。

9 复制与一致性 无主对等复制

可调一致性官方文档。无主对等复制；每查询指定一致性级别（ONE / QUORUM / LOCAL_QUORUM / ALL 等）；W+R>N 保证读写集合交集；副本缺失时靠 hinted handoff（默认 3 小时窗口）+ read repair + 周期性 anti-entropy repair 收敛。ScyllaDB 语义相同，数据分布层自 2025.1 默认 tablets（替代 vnodes，Raft 负载均衡）。

10 扩展方式 横向 scale-out，在线

横向 scale-out，在线官方文档。加节点自动分担 token/tablet 范围；Cassandra 4.0 起符合条件的 SSTable 走零拷贝 streaming（官方口径，扩容快 5 倍为厂商口径）；ScyllaDB tablets + 文件级 streaming 使加节点更快（30 倍为厂商口径，见深水区）。

11 兼容性 部分支持

部分支持官方文档 社区共识。CQL（类 SQL 但无 join/子查询/任意 WHERE）；多语言官方驱动；Spark/Hadoop 连接器；ScyllaDB 额外兼容 Amazon DynamoDB API（Alternator），DynamoDB 应用可低改迁移（官方口径）。Cassandra 5.0 新增 SAI 与向量索引，补齐部分二级索引/相似检索场景。

12 许可证与商业模式 Cassandra：Apache

  • Cassandra：Apache 2.0 纯开源；商业围绕服务与托管：DataStax（DSE 企业版、Astra DB Serverless 按读写请求量计费）2025 年 5 月被 IBM 收购并入 watsonx.data（公开报道）；另有 K8ssandra 等云原生发行版。
    • ScyllaDB：2025.1 起 source-available 统一版本（官方公告 2024-12）；免费额度为每组织 10TB 配置磁盘 + 50 vCPU（跨所有集群，官方 FAQ 口径），超出需商业许可；6.2 AGPL 为最后一个纯开源版本；托管为 ScyllaDB Cloud / X Cloud（按节点/资源计费模型，具体单价以官网为准，此处不引用）。

13 中文资料丰富度 Cassandra 中等

Cassandra 中等（官方文档以英文为主；CSDN/博客中文教程多，但大量内容停留在 3.x/4.0 时代）；ScyllaDB 较少（官方英文文档为主，中文社区内容稀缺）——均为社区共识。

14 性能与延迟特征 有

有（写吞吐随节点扩展的标杆；读看调优）。

  • Cassandra：加节点即加写吞吐，调优得当单集群百万写入/秒量级（视硬件，社区实测）社区实测。
  • ScyllaDB（C++ 重写）官方称单节点数倍于 Cassandra厂商口径；seastar 分片-per-core 架构 厂商口径。
  • 读 P99 取决于 compaction 策略与布隆过滤器调优；跨数据中心复制延迟可配 社区共识。

15 合规与认证 部分支持

部分支持（开源无官方认证；企业版各走各）。

  • Apache Cassandra 开源版：无官方合规认证 社区共识。
  • DataStax Enterprise / ScyllaDB 企业版各自持有企业合规资质厂商口径厂商口径。
  • 云厂商托管版继承云厂商资质 厂商口径。

16 成熟度与社区生态 有

有（Cassandra 2008 开源；ScyllaDB 2016 开源）。

  • Cassandra：2008 年 Facebook 开源，2010 年 Apache 毕业；老牌分布式宽列 社区共识。
  • ScyllaDB：2015 年成立，C++ 重写，DynamoDB 兼容是差异化 社区共识。
  • 两者社区都活跃，但新增项目热度不如向量/Serverless 新贵 社区共识。

17 标杆用户 有

有（Netflix、Apple、Discord）。

  • Netflix、Apple、Discord 等公开大规模用户 社区共识。
  • Discord 从 Cassandra 迁到 ScyllaDB 是著名案例（公开博客）社区共识。
  • 国内大厂（字节/快手等）有规模化使用 社区共识。

18 生态工具链 有

有（Medusa 备份；sstableloader 迁移）。

  • 备份：nodetool snapshot；Medusa（Spotify 开源，S3 备份编排）社区共识。
  • 迁移：sstableloader；ScyllaDB 有 DynamoDB/Cassandra 迁移工具 社区共识。
  • CDC：Debezium Cassandra 连接器；监控：JMX exporter 社区共识。

19 云托管与 Serverless 有

有（Astra Serverless；ScyllaDB Cloud）。

  • DataStax Astra：Serverless 按量 厂商口径。
  • ScyllaDB Cloud：托管 ScyllaDB 厂商口径。
  • 各云也有 Keyspaces 等兼容托管 社区共识。

20 数据接入与摄入 有

有（DSBulk/sstableloader；cqlsh COPY 只适合小数据）。

  • DSBulk（DataStax Bulk Loader）是生产级批量导入/导出工具 官方文档。
  • sstableloader 可直接加载 SSTable（ScyllaDB 同理）官方文档。
  • cqlsh COPY 单线程慢只适合小表；大宽行注意超时 社区共识。

21 外部数据访问 部分支持

部分支持（无外部表；靠 Spark Connector 做分析侧联邦）。

  • CQL 无外部表/联邦查询语义 社区共识。
  • Spark Cassandra Connector 可把 C* 当数据源做离线分析 官方文档。
  • ScyllaDB 兼容同一套连接器 厂商口径。

22 CDC 与下游同步 有

有（Scylla CDC 日志表；C* 4.0+ CDC；Debezium）。

  • ScyllaDB：按表开启 CDC，变更写入专用日志表供消费 官方文档。
  • Cassandra 4.0+：cdc_enabled 提交日志式 CDC，需自行消费 官方文档。
  • Debezium 有 Cassandra/Scylla 连接器（社区成熟度不一）社区共识。

23 TTL 与数据生命周期管理 有

有（列级/表级原生 TTL，写入时指定）。

  • INSERT/UPDATE 可带 USING TTL（列级过期），表级 default_time_to_live 官方文档。
  • 过期数据靠 compaction 回收，墓碑（tombstone）堆积会拖慢读 社区共识。
  • TTL 重度场景建议调小 gc_grace_seconds 并监控 tombstone 比例 社区实测。

24 在线 DDL 与 Schema 演进 部分支持

部分支持（加列轻量但 schema 变更最终一致）。

  • 此处的 schema 演进即 CQL 的 ALTER TABLE：加列/删列属"只改定义不碰数据"类，官方文档明确为常量时间操作，不重写数据 官方文档。
  • 主键/聚簇键建表后永远不可改，改需重建表导数据（"搬数据"类，但无在线路径） 官方文档。
  • 删列内容在 compaction 时懒删除；删列后重建同名列允许，除非原列是非 frozen 的集合类型 官方文档。
  • schema 变更经 gossip 在集群内最终一致传播：混合版本期读写可能异常，并发 DDL 可能导致 schema 不一致，生产变更后用 nodetool describecluster 确认各节点 schema 一致 社区共识。
  • ScyllaDB 的 schema 变更做了 Raft 化改进，一致性更好 官方文档。
  • 语义注记：CQL 没有 CHECK/外键/默认值约束，ADD 列不校验已有数据，"验证约束"类在此系统基本缺席 官方文档。

25 多租户与资源隔离 部分支持

部分支持（keyspace 逻辑隔离；无资源限流）。

  • keyspace 做逻辑隔离，但无 CPU/IO 限流，一个租户可拖慢全集群 社区共识。
  • ScyllaDB 有 workload 优先级调度，比开源 Cassandra 好一些 官方文档。

26 跨地域多活 有

有（多 DC 原生，副本策略跨机房）。

  • NetworkTopologyStrategy 按 DC 放副本，天然跨地域 官方文档。
  • LOCAL_QUORUM 就近读写，EACH_QUORUM 强一致但延迟高 官方文档。
  • 跨区延迟直接加到写路径，机房间网络质量决定体验 社区共识。

27 高可用架构与 RTO/RPO 有

有（无单点；节点故障自动绕过）。

  • 对等架构无主节点，单节点故障客户端自动绕过，RTO≈0（读/写按一致性级别降级）官方文档。
  • RPO 取决于一致性级别，ONE 级别可能丢数 官方文档。
  • hinted handoff + 修复保障最终一致 官方文档。

28 行级安全与数据脱敏 无

无（无原生行级安全与脱敏）。

  • Cassandra / ScyllaDB 无原生行级安全与动态脱敏 社区共识
  • 权限只到 keyspace / table 级，无列级权限 官方文档
  • 行级隔离靠应用层或不同 keyspace 物理隔离 社区共识

29 JSON 与半结构化能力 部分支持

部分支持（集合类型；JSON 文本存取）。

  • CQL 有 map/list/set 集合类型，可表达嵌套结构 官方文档。
  • 无原生 JSON 类型；ScyllaDB 支持 INSERT/SELECT JSON 语法糖，底层仍为文本/集合 官方文档。
  • 集合过大导致分区膨胀，生产建议控制元素数量 社区共识。

30 全文检索能力 部分支持

部分支持（SASI 非分词；生产多外挂 ES）。

  • SASI 二级索引支持前缀/contains 匹配，但非分词全文检索 官方文档。
  • 生产全文场景普遍外挂 ES/Solr，数据双写一致性自负 社区共识。

31 存储效率与压缩 有

有（LSM+SSTable 压缩；写放大显著）。

  • LSM 架构下 SSTable 支持多种压缩（LZ4/Snappy/Deflate/ZSTD），压缩比高。官方文档
  • LSM 写放大（compaction 反复重写）是存储效率的主要损耗，需调优压缩策略与 compaction。社区实测
  • ScyllaDB 的分片-per-core 架构减少 compaction 抖动，压缩效率更稳定。厂商口径

32 开源协议与厂商锁定风险 部分支持

部分支持（Cassandra 开源；ScyllaDB 双版本）。

  • Apache Cassandra 为 Apache 2.0 社区开源，无协议变更黑历史。官方文档
  • ScyllaDB 采用开源/企业双版本策略，企业版部分高级特性闭源，存在功能分层。厂商口径
  • 两者协议兼容（CQL），生态可互替，锁定风险低。社区共识

33 查询优化器与计划稳定性 部分支持

部分支持（无 CBO：靠建模，计划简单可预测）。

  • Cassandra 无代价优化器，查询性能由数据建模（分区键设计）决定，计划可预测但无自动优化 官方文档。
  • ALLOW FILTERING 全表扫描是经典生产事故源 社区共识。
  • ScyllaDB 保持 CQL 兼容，同样无 CBO 官方文档。

34 参数调优与自治能力 部分支持

部分支持（Cassandra 参数上百；ScyllaDB 自调优）。

  • cassandra.yaml 上百参数，调优高度依赖建模与 compaction 策略 官方文档。
  • ScyllaDB 按分片自动调优，运维负担明显更低 官方文档。
  • 诊断靠 nodetool/JMX，自治能力弱 社区共识。

35 静默数据损坏防护 部分支持

部分支持（SSTable 读写压缩时校验，无页级自愈）。

  • SSTable 在压缩与读写路径带校验，发现损坏可丢弃坏文件并从副本重建。官方文档
  • 无 InnoDB 式的常驻页 checksum 开关；副本间分歧靠 repair / read-repair 收敛。社区实测
  • 静默损坏若恰好落在所有副本同一位置，可能长期潜伏。社区共识

36 存储过程/触发器/过程语言 无

无（查证为无存储过程/触发器）。

  • CQL 无存储过程、触发器、过程语言（查证为无）官方文档。
  • 逻辑只能放在应用层或 Spark/DSE Analytics 侧 社区共识。

37 约束与数据完整性 无

无（无外键/CHECK；应用层保证）。

  • 无外键、CHECK、唯一约束（轻量事务仅条件写入）官方文档。
  • 完整性靠应用层与反范式数据建模保证 社区共识。

38 分析 SQL 完备性 无

无（CQL 无窗口函数/CTE）。

  • CQL 无窗口函数、CTE、JOIN（查证为无）官方文档。
  • 分析靠 Spark 连接器或 DSE Analytics 社区共识。

39 被遗忘权与数据擦除 部分支持

部分支持（墓碑残留；gc_grace_seconds窗口）。

  • DELETE 写墓碑（tombstone），在 gc_grace_seconds（默认 10 天）内物理残留，压缩后才彻底消失 官方文档
  • 墓碑堆积会引发读放大与“僵尸数据”复活风险，是运维与合规的双重坑 社区实测
  • 快照、增量备份、repair 流转的数据都会延长残留期 官方文档
  • 无擦除证明，GDPR 场景需编排“删除 + 等待 GC + 清理快照” 社区共识

40 数据血缘与目录集成 无

无（查证为无原生血缘）。

  • 无原生数据血缘/目录功能 官方文档。
  • 需第三方数据治理平台对接 社区共识。

41 存算分离 vs 存算一体 有

有（存算一体：本地盘 LSM）。

  • 经典存算一体：每节点本地盘存 SSTable，扩缩容需数据重分布 官方文档。
  • 本地盘带来高吞吐与低延迟，但弹性差 社区共识。

42 多模能力 无

无（宽列+集合类型，无向量/全文/图）。

  • 模型限宽列、集合/UDT，无原生向量、全文、图能力 官方文档。
  • Stargate 等网关可转协议但不改变模型 社区共识。

43 FinOps 成本可观测性 不适用

不适用（自建无计费，成本=硬件+运维人力自理）。

  • 开源自建无内置计费概念，成本是节点硬件、存储与运维人力。社区共识
  • 托管版（如 Astra DB）可在云账单侧做标签归因。厂商口径

44 驱动与多语言生态 有

有（DataStax 驱动矩阵全；JDBC 靠 Simba）。

  • DataStax 官方 Java/Python/Node/Go/C# 驱动成熟 官方文档。
  • JDBC/ODBC 靠 Simba 等第三方驱动 社区共识。

45 物化视图 部分支持

部分支持（物化视图限制多，运维负担重）。

  • 支持物化视图，但基表写入放大、修复运维负担重，限制多 官方文档。
  • 社区普遍建议用应用层双写宽表替代 社区共识。

46 支持跨云 有

有（开源任意云；ScyllaDB Cloud 多云）。

  • 开源版任意云/自建可部署，无厂商绑定 官方文档。
  • ScyllaDB Cloud 支持 AWS/GCP，跨云靠自建集群 官方文档。
  • 跨云延迟进 gossip/复制路径，网络质量关键 社区共识。

47 热点数据更新能力 有

有（无锁 LWW 写永不冲突，热点分区靠建模扛）。

  • 并发控制原语是无锁追加写 + LWW：同一行并发写直接落 commitlog/memtable，以客户端时间戳定胜负，不存在锁等待、死锁、写冲突 abort，内核无需重试；写超时（coordinator 超时）由驱动按重试策略重发（驱动层），幂等写可安全重放。需要线性 CAS 时用 LWT（Paxos compare-and-set，Cassandra 4.1+ 可切 Paxos v2 降延迟），代价是多轮往返——热点 key 下 Paxos 串行化成瓶颈，热计数器禁用 LWT官方文档。
  • 衰减形态：热点打到同一分区键，该分区的副本集（RF=3 即三个节点）CPU/IO/压缩压力陡增；超大分区（官方口径 >100MB 或 10 万 cell）还会引发 GC 停顿与读延迟毛刺；coordinator 对跨分区 batch/查询做汇聚，多分区 batch 反而加重协调者压力（官方：batch 为原子性而非性能，反模式）。读热点可被副本分摊，写热点不行——写必须走负责该 token 范围的副本集。ScyllaDB 2025.1+ 默认 tablets 按负载自动均衡 token 范围，但单个热分区键仍固定在一个 tablet/分片，加节点不分摊单 key 热度官方文档。
  • 内置缓解：未找到官方命名或文档化的热点行打散/自动迁移机制的证据（不是查证为无，靠应用层/建模）；可观测性侧有 nodetool tablehistograms 与表级指标定位热分区——检测手段，不是缓解。版本边界：ScyllaDB tablets（2025.1 默认）改善的是范围级负载均衡，不是 key 级打散待验证。
  • 应用层模式与代价：分区键加桶（如 (user_id, bucket)，Discord 按 10 天窗口分桶）把热分区拆成多个物理分区（代价：读需扇出 N 个分区合并，应用逻辑变复杂）；热计数器用分片计数器（N 行累加，代价：读时求和、短暂不一致）；读热点前置缓存（代价：只解决读，写热点无效，另有失效复杂度）；网关层对热 key 限流（代价：牺牲部分可用性）社区共识。

招牌能力

  1. 无主对等架构 + 可调一致性：为"写不能停"而生 真本事：没有主从之分，任何节点都可做 coordinator；一致性级别按查询指定——LOCAL_QUORUM 在多活跨 DC 部署下兼顾延迟与正确性。这是 Cassandra 系在断网、单 DC 故障下仍能写入的根本原因。 边缘真相：见深水区一——quorum 数学只保证"读写集合相交"，不保证"所有副本最终收敛"；后者靠 repair，而 repair 是运维动作不是自动魔法。
  2. 水平扩展：加机器就扩容 真本事：shared-nothing，加节点、数据自动重分布，在线完成；从 3 节点到上百节点的扩展曲线是这一品类立身之本（Apple、Netflix 级部署是公开报道的背书）。 边缘真相：扩容期间 streaming 吃网络与 IO，高峰期扩容等于给飞行中的飞机换引擎；Cassandra vnode 拓扑下大集群加节点历史上偏慢（ScyllaDB 的 tablets 正是为治这个）。
  3. ScyllaDB 的 shard-per-core 重写：把多核吃干抹净 真本事：C++ / Seastar，每核一个独立 shard，无共享内存、无 GC、无锁，用户态 IO 调度；同等吞吐所需节点数显著少于 Cassandra（TCO 优势的来源，独立测试多观测到 2x 起，10x 多为厂商口径）。 边缘真相：见深水区四——热点分区仍受单个 shard 上限约束；对硬件亲和（NUMA、本地 NVMe）要求高，超售严重的虚拟化环境收益打折。
  4. Cassandra 5.0 的 SAI + 原生向量搜索：查询能力的补课 真本事：Storage-Attached Indexes（SAI）把二级索引做进存储引擎，终结了传统二级索引"全集群 fan-out"的痼疾；原生向量与 ANN 搜索让 Cassandra 能直接服务 RAG/推荐场景。 边缘真相：这些能力只在 5.0+，3.11/4.x 老集群享受不到；SAI 仍不是关系型索引的替代品，query-first 建模的纪律不能丢。
  5. ScyllaDB Alternator：DynamoDB 的逃生舱 真本事：线级兼容 DynamoDB API，DynamoDB 用户可不改应用逻辑迁移，顺带甩掉按请求计费的账单（"sticker shock"是官方反复引用的迁移动因）。 边缘真相：兼容的是 API 不是 DynamoDB 的运维语义（限流、分区行为仍是 ScyllaDB 内核）；DynamoDB 的强一致读/GIS 等高级语义需逐项验证。

深水区

深水区一：可调一致性——quorum 只保证相交，不保证收敛

  • 机制：无主复制，写时 coordinator 按一致性级别等待 W 个副本确认；读时等待 R 个副本，取最新时间戳。W+R>N 保证读写集合必有交集。
  • 推到边缘：某节点宕机超过 hinted handoff 默认 3 小时窗口 → hint 被丢弃 → 该节点永久缺失这批写入；之后它恢复并参与 R=2 的读，读到的可能是旧值；若周期性 repair 也没跑，这批 key 将静默分歧——quorum 数学对此无能为力（社区教学案例实证）。CL=ALL 则任一副本抖动就写失败，可用性雪崩。
  • 选型含义：最终一致性是"运维出来"的——repair 排期必须写进 runbook，且周期 < gc_grace_seconds；跨 DC 部署默认用 LOCAL_QUORUM 而非 QUORUM。
  • 来源：社区技术文档（rustyrazorblade/cassandra-expert repair/hinted-handoff，2026-09 更新）、tub99 分布式系统教学案例。

深水区二：tombstone 与 repair——删除是最贵的写

  • 机制：SSTable 不可变，删除 = 写 tombstone 标记；tombstone 在 gc_grace_seconds（默认 10 天）后才允许被 compaction 清除；清除前所有副本必须经 repair 见过这个 tombstone。
  • 推到边缘：批量删除/集合整列替换/SET col = null 会制造 tombstone 风暴 → 读要穿越海量墓碑，读放大、堆内存压力，超 tombstone_failure_threshold（默认 10 万）查询直接失败；把 gc_grace_seconds 调得比 repair 周期短 → 墓碑提前清除 → 错过删除的副本在下次 repair 时把已删除数据复活（zombie rows），且静默无报错。
  • 选型含义：能 TTL 过期就别显式 DELETE；repair 周期必须 < gc_grace；监控 TombstoneScannedHistogram；时间序列场景优先按时间分表 + 整表 DROP（零墓碑）。
  • 来源：社区技术文档（tombstones/repair 参考，2026-09 更新）、heatware 实测指南。

深水区三：hinted handoff——只有 3 小时的临时桥

  • 机制：副本短暂不可用时，coordinator 把写暂存为本地 hint（max_hint_window_in_ms 默认 3 小时），节点恢复后重放。
  • 推到边缘：三种丢 hint 的方式——(1) 节点宕机超 3 小时，hint 直接丢弃；(2) coordinator 自己崩溃，hint 随它陪葬（hint 不复制）；(3) hint 堆积打满 max_hints_size_per_host_in_mb，新 hint 被丢弃。以及故障检测器没及时发现的"半死"节点：写超时但 hint 已存，coordinator 内存压力堆积甚至抛 OverloadedException 拒绝写入。
  • 选型含义：hinted handoff 不是 repair 的替代品；任何超窗口的宕机恢复后必须跑 repair；CL=ANY（"hint 算成功"）语义危险，生产慎用。
  • 来源：官方文档概念、社区运维手册（2026-09 更新）。

深水区四：ScyllaDB shard-per-core——快，但按 shard 思考容量

  • 机制：Seastar 框架，每 CPU 核一个 shard，各自拥有内存、memtable/SSTable、缓存分区、网络连接与 IO 调度队列；shard 间只经消息传递通信，无共享状态。
  • 推到边缘：热点分区（partition key 高度集中）仍受单个 shard 的吞吐上限约束，加核不解决问题，得从建模层打散；跨 shard 的聚合/全局二级索引查询有消息汇聚开销；云上超售 vCPU、远端盘场景下"贴近硬件"的设计收益会被吃掉一部分。
  • 选型含义：容量规划按 shard 不是按节点；热点 key 建模评审与 Cassandra 同等重要；压测必须用生产级硬件形态，笔记本/超售云主机上的数字没有意义。
  • 来源：ScyllaDB 官方产品页、社区架构分析（softwaremill 2026-09）、维基百科（独立测试 2x~10x 差异的综述）。

深水区五：ScyllaDB 许可证——2025 年后不再是"开源免费"

  • 机制：2024-12 官方宣布、2025.1（2025-04 发布）起 OSS 与 Enterprise 合并为统一的 source-available 版本；最后一个纯开源版本是 AGPL 的 6.2；免费额度为每组织 10TB 配置磁盘 + 50 vCPU（跨所有集群，官方 FAQ 口径）。
  • 推到边缘：超出免费额度的集群需商业许可——此前按"开源免费"做的 TCO 预算要重算；云厂商/大客户法务需审查 source-available 条款（与 OSI 开源定义不兼容）；AGPL 6.2 理论上可被社区分叉，但分叉版拿不到后续 tablets/Raft 等演进。
  • 选型含义：新部署直接按商业条款做预算与法务评估；小规模/评估场景免费额度通常够用；把"许可证变更风险"写进选型纪要。
  • 来源：ScyllaDB 官方公告（2024-12-18）、官方产品 FAQ、第三方分析（softwaremill 2026-09）。

深水区六：Cassandra 4.x/5.0 现状——老用户是时候升级了

  • 机制：截至 2026-09，5.0.9 为最新 GA；5.0 带来 SAI、原生向量搜索、统一压缩策略（UCS）、动态数据脱敏、mTLS 认证；5.0.8+ 把自动 repair 调度 backport 为可选项（opt-in）；6.0 仍为 pre-GA（alpha），在研事务性集群元数据与 Accord 跨分区事务。
  • 推到边缘：3.11 老集群的升级是"逐级跳"（3.11→4.x→5.0），SSTable 格式单向升级不可回退，升级窗口要留足验证时间；5.0 的 SAI/向量/auto-repair 老版本一概没有，"等 6.0 的 Accord"属于期货，不能进当前选型决策。
  • 选型含义：新部署直接 5.0.x；现存 3.11/4.0 集群先规划升级路径再评估新特性；把 Accord/6.0 当作跟踪项而非决策依据。
  • 来源：ASF 5.0 发布公告、第三方版本综述（softwaremill 2026-09，确认 5.0.9 为最新 GA）。

客户经验

内核 LSM 追加写：吃下"写多读少、只追加"的消息流

一句话
宽列 + LSM-tree 存储引擎，为"海量追加写、极少改删、按时间范围读"的 workload 而生；写路径是 memtable + commit log 顺序追加，天然吞掉写入洪峰。
窄场景
聊天消息/事件流这类 workload——每天数十亿条写入、几乎不修改、极少删除、读取按 `(channel_id, 时间桶)` 范围扫描；团队处于从单机 MongoDB 向分布式演进的阶段。
机制
MongoDB 的 B-tree 模型下，数据 + 索引必须能塞进内存才能保证延迟，这是随机写/随机读放大的结果，不是调参能解决的。Cassandra 的 LSM 写路径永远是顺序追加；宽列模型的 `(channel_id, bucket)` 分区键 + `message_id` 聚类键，让"同一频道按时间读"变成一次分区内的顺序扫描——这正是 LSM 最舒服的形状。
生产验证
Discord 官方工程博客《How Discord Stores Billions of Messages》（2017，一线工程师撰写）：2015 年底存到约 1 亿条消息时，MongoDB 数据和索引塞不进 RAM，延迟不可预测；迁到 Cassandra 后 12 节点、复制因子 3 时读 <5ms、写亚毫秒（https://discord.com/blog/how-discord-stores-billions-of-messages）；2023 年续篇回顾确认了这段历史（https://discord.com/blog/how-discord-stores-trillions-of-messages）。
竞品差距
MongoDB——B-tree 模型，在该 workload 下先撞内存墙（Discord 亲历）；ScyllaDB——同一宽列模型 + LSM，机制相同，是"换引擎"而非"换模型"；DynamoDB——分区键模型类似，但 serverless 计费在该量级下成本不可比。
证据等级
社区实践（一线工程师生产分享，非厂商稿）。厂商 vs 用户无明显错位：官网也讲"write fast"，但工程师记住的是"1 亿条消息时 MongoDB 延迟不可预测"这个具体断裂点。
最后核验
2026-10-01

内核 ScyllaDB：shard-per-core 消灭 JVM GC 的运维税

一句话
与 Cassandra 线协议兼容（CQL 直接复用、数据模型零改动），但用 C++ Seastar 实现 shard-per-core 架构：每个 CPU 核独占内存分区与 I/O 队列，无 GC、无跨核锁竞争；同等 workload 下节点数减半以上、p99 延迟收敛一个数量级。
窄场景
已经跑在 Cassandra 上、被 GC 停顿和 compaction 债务折磨、但宽列数据模型不想重写的团队；workload 是 Discord 式的万亿级消息。
机制
Cassandra 的痛不是模型，是 JVM：GC 停顿导致延迟毛刺，严重时要人工重启"哄"节点回健康；compaction 落后时要玩"gossip dance"（把节点踢出集群让它慢慢 compact）。ScyllaDB 的 shard-per-core 让每个核独立处理自己分片的数据，没有全局 GC 线程、没有跨核锁。诚实备注：Discord 还配套做了 Rust data services（一致性哈希路由 + 请求合并），热分区保护主要靠这层，不是数据库本身——ScyllaDB 官方博客常把这部分功劳模糊掉。
生产验证
Discord 官方工程博客《How Discord Stores Trillions of Messages》（2023-03-06，作者 Bo Ingram）：177 个 Cassandra 节点 → 72 个 ScyllaDB 节点（单节点磁盘 4TB→9TB）；读 p99 从 40–125ms → 15ms；写 p99 从 5–70ms → 稳定的 5ms；自研 Rust 迁移器峰值 320 万条消息/秒、9 天完成数万亿条迁移（https://discord.com/blog/how-discord-stores-trillions-of-messages）。Discord 原文也承认："ScyllaDB 绝不是没有问题，它只是没有垃圾回收器"。
竞品差距
Cassandra——同一模型，JVM GC 是代差级差距；其余 30 款中没有线协议兼容 Cassandra 的替代品。
证据等级
社区实践（一线工程师生产分享）。
最后核验
2026-10-01

避坑 tombstone 读放大："删除"是最贵的写操作

一句话
分布式删除只能先写 tombstone 标记、靠 compaction 物理清除；读路径要合并 memtable + 多个 SSTable 并扫过所有 tombstone 才能找到活数据，高删除/TTL workload 下读延迟爆炸、查询甚至被直接 abort。
窄场景
凡是有"批量删除""TTL 过期""消息撤回"语义的 workload，都是这个反向招牌的靶场；纯追加 workload 则无感（这正是第一张卡片能成立的原因）。
机制
LSM 不做原地更新，删除 = 写入一个带时间戳的 tombstone 标记；读时要对多个 SSTable 做归并，tombstone 必须全部扫过才能确认"这行真的死了"。Cassandra 默认单查询扫描超过 100K 个 tombstone 就 abort 查询。Discord 迁移时迁移器卡在 99.9999% 就是因为"从未被 compact 掉的巨型 tombstone 区间"；Discord 早年一次删掉数百万条消息的生产事故后，被迫把 tombstone 存活期从 10 天砍到 2 天。
生产验证
Discord 官方博客（https://discord.com/blog/how-discord-stores-trillions-of-messages）；一线 DBA Krishna Alapati 的排障记录："Read 600 live rows and 16,526 tombstone cells"——96% 的扫描量是已删除数据（https://medium.com/@lkalapati.dba/cassandra-performance-stabilization-497e40ec42d7）；Pandu Boyina 的事故复盘：TTL 误删关键记录后 tombstone 不可查、不能直接重插，被迫 dump + 改系统时间绕回（https://medium.com/@pandu.boyina/lessons-learned-cassandra-ttl-tombstones-and-reprocessing-deleted-data-080441cf0346）。
竞品差距
ScyllaDB——同 LSM 模型，同样有 tombstone，无差距；DynamoDB——TTL 删除是后台免费异步删，不经过读路径；B-tree 系（PostgreSQL/MySQL）删除即标记可见性，无跨 SSTable 归并扫描。
证据等级
社区共识（多个独立生产事故指向同一机制）。诚实备注：官方文档把 tombstone 写成中性机制说明；用户侧的真实体感是"最贵的操作"，官网首页不会告诉你这个。
最后核验
2026-10-01

避坑 可调一致性的运维税：gossip dance 与 compaction 死亡螺旋

一句话
Cassandra 把一致性、compaction、repair 的控制权交给你，代价是 on-call 团队长期支付"调 JVM 堆、哄 GC、踢节点做 compaction、跑 repair"的运维税；节点数越多税越重。
窄场景
当集群从 12 节点涨到 177 节点，维护工作量随存储量线性增长——Discord 原话："我们想要一个随我们成长、但维护需求不随存储增长的数据库，结果事与愿违"。
机制
LSM 的读放大靠 compaction 压住，但 compaction 本身是重 I/O 操作，忙时会被流量饿死 → SSTable 越积越多 → 读更慢 → 需要更多 compaction（死亡螺旋）。Discord 的解法是"gossip dance"：把节点踢出集群让它专心 compact，再接回来接 hinted handoff，如此往复。另有 JVM GC 停顿 → 节点被 gossip 判 DOWN → 客户端重试风暴 → 更多堆压力（GC 死亡螺旋）。这两件事在 2022 年的 Discord 是 on-call 被频繁 pager 的主因。
生产验证
Discord 官方博客（https://discord.com/blog/how-discord-stores-trillions-of-messages），"high-toil system"、"gossip dance"、"手动重启并 babysit 节点恢复健康"均为原文措辞。
竞品差距
DynamoDB——serverless 零运维，是光谱的另一端（代价是计费）；ScyllaDB——同模型但 compaction 与调度更高效，运维税显著更低；其余自运维产品单节点运维心智完全不同，不直接可比。
证据等级
社区实践（一线工程师生产分享）。诚实备注：官网营销关键词是"linear scalability, no single point of failure"；用户实践的结论是"scale 得上去，但每 GB 的运维 toil 也在涨"——这是"能扩展" vs "扩展得省心"的区别，选型时最容易踩的坑。
最后核验
2026-10-01

用户最买账的 5 点

  1. "永远在线"的写可用性口碑
    • 为什么是真的：无主架构 + hinted handoff + 可调一致性，单节点甚至单 DC 故障下写路径不中断；这是从 Facebook 收件箱/Digg 时代一路验证下来的核心资产。
    • 边缘与限度：可用性的代价是"一致性靠运维"——repair、hint 窗口、gc_grace 三者配错会出现静默分歧；CL=ALL 下可用性优势荡然无存。口碑成立的前提是团队愿意为最终一致性配运维纪律。
  2. 加机器就扩容的水平扩展
    • 为什么是真的：shared-nothing + 一致性哈希，扩容是在线的数据重分布，不停服；从个位数节点到数百节点的案例是公开报道过的。
    • 边缘与限度：Cassandra vnode 拓扑下大集群加节点历史上偏慢且不均；扩容期的 streaming 与数据均衡吃网络 IO，高峰期扩容要选低峰窗口；以及很多人高估了自己对"百节点扩展"的真实需求。
  3. ScyllaDB 的 p99 稳定性（无 GC 停顿）
    • 为什么是真的：C++ 无 GC + 每 shard 独立 IO 调度，延迟毛刺主要来自硬件而非运行时；延迟敏感型业务（广告、实时推荐）这是换 ScyllaDB 的第一动因。
    • 边缘与限度：p99 稳不等于 p9999 稳，跨 shard 查询、compaction 毛刺依然存在；收益与硬件亲和强相关，超售云主机上测不出宣传数字；独立测试的加速比从 2x 到 10x 不等，厂商的 10x 按厂商口径理解。
  4. CQL 生态与驱动成熟度
    • 为什么是真的：CQL 形似 SQL 学习曲线平缓；Java/Python/Go 等官方与社区驱动均为 token-aware，生态工具（Medusa、Reaper、K8ssandra、各类 exporter）齐全；ScyllaDB 复用同一套驱动与 SSTable 格式，迁移 friction 低。
    • 边缘与限度：生态成熟的是"操作面"，不是"查询面"——CQL 的表达能力天花板（无 join）不会因驱动成熟而提高；ScyllaDB 专用能力（shard-aware）要用它的专用驱动才吃满。
  5. 互联网大厂十年验证
    • 为什么是真的：Cassandra 侧有 Netflix 等公开站台（5.0 发布时官方引述其 LWT 50% 提升受益）；ScyllaDB 侧有 Discord（万亿级消息）、Comcast、Samsung 等（厂商公开客户名单，客户名本身为公开报道）。
    • 边缘与限度：大厂的验证结论绑定它们的 workload（写密集、key-value 型访问）；"Discord 能跑"不等于"你的复杂查询能跑"；客户名单是厂商口径，POC 仍要用自己的读写模型压。

吐槽清单

分类吐槽影响版本状态
运维坑tombstone 风暴导致读放大、查询超时（tombstone_failure_threshold 默认 10 万直接失败）全版本open
运维坑repair 是强制性周期运维，不跑会有静默分歧；大集群 repair 本身耗时且吃资源全版本partially-fixed（5.0.8+ auto repair opt-in backport）
运维坑gc_grace_seconds 与 repair 周期配错导致已删除数据复活（zombie rows），且无报错全版本open（配置纪律问题）
性能坑LWT 走 Paxos，约数倍于普通写的延迟与开销；热点分区上竞争加剧甚至超时全版本partially-fixed（4.1+ Paxos v2 / CEP-14 降到写 2 RTT）
性能坑传统二级索引全集群 fan-out、物化视图有已知一致性边缘情况，生产慎用全版本partially-fixed（5.0 SAI 解决索引 fan-out；MV 仍实验性）
兼容坑CQL 无 join/子查询，查询必须事先建模（query-first），关系型思维迁移阵痛大全版本open（by design）
运维坑单分区 2GB 硬限制，大分区导致堆内存/压缩/修复全方位恶化全版本open
运维坑ALLOW FILTERING 轻易写出全表扫描；跨分区 batch 比单条写更慢（coordinator 开销 + batchlog）全版本open
运维坑大版本升级单向不可回滚；3.11→5.0 需逐级升级，升级窗口规划成本高全版本open
运维坑Cassandra 官方无内置 Prometheus/Grafana 端到端监控栈，需自拼 exporter全版本open
授权坑ScyllaDB 2025.1 起改为 source-available，超免费额度（10TB/50vCPU）需商业许可2025.1+open
生态坑ScyllaDB 中文资料稀缺、社区规模小于 Cassandra，疑难问题更依赖原厂/英文社区全版本open
运维坑ScyllaDB Manager 恢复不支持 Authentication 与 Service Levels 还原（官方仓库文档注明）全版本open（按官方集成测试矩阵）

判决

  • 一句话定位：写密集、永远在线、水平扩展场景的默认选项之一；要生态与许可证中立选 Cassandra，要单机性能与低运维选 ScyllaDB（接受新许可证）。
  • 适合谁：
    • 日均写入亿级、key-value 型访问的物联网/日志/埋点/用户行为存储；
    • 多活跨 DC、"写不能停"优先于"强一致"的业务；
    • 已有 Cassandra 生态、想以更少节点降本的团队（→ ScyllaDB）；
    • 想逃离 DynamoDB 按请求计费账单且应用改动预算小的团队（→ ScyllaDB Alternator）；
    • 需要在宽列模型上做向量/相似检索的新业务（Cassandra 5.0+）。
  • 不适合谁：
    • 需要多行 ACID 事务、复杂 join/聚合的业务（这是关系型的地盘）；
    • 读多写少且要求强一致读的场景；
    • 团队无专职运维又想"装完不管"（自建版 repair/tombstone/升级都是活；这种情况请用托管版）；
    • 法务不接受 source-available 且数据规模超免费额度的（ScyllaDB）。
  • 迁移成本：
    • MySQL → 高：数据模型重构（query-first、反范式、无 join），应用数据访问层重写；CQL 形似 SQL 是陷阱，语义完全不同。
    • PostgreSQL → 高：同上；PG 的复杂查询/事务能力在 CQL 里没有对应物。
    • Oracle → 高：同上；且 Oracle 生态的存储过程/触发器需应用层重构。

来源与待验证清单

  • 版本信息：softwaremill《If You Last Used Cassandra 3.11…》（2026-09，确认 5.0.9 为最新 GA、6.0 pre-GA）；libredb 实测记录（2026-08-20 验证 5.0.9）；ScyllaDB 官方 Version Support 页（2026.3/2026.2/2026.1 LTS/2025.1 LTS）；ScyllaDB 论坛 release 公告（2026.1.10，2026-08）
  • 5.0 特性口径：ASF 官方发布公告（globenewswire，SAI/向量搜索/动态脱敏/mTLS）；softwaremill 版本综述（UCS、auto repair backport、Accord/6.0 在研）
  • 机制与运维：rustyrazorblade/cassandra-expert 参考文档（tombstones/repair/hinted-handoff/LWT/security，2026-09 更新）；heatware tombstone 实测指南；devweekends 集群运维手册
  • ScyllaDB 架构与许可：官方产品页（shard-per-core/Alternator/Cloud 加密）；官方许可证变更公告（2024-12-18）；linuxiac 报道；softwaremill tablets/Raft 分析（2026-09）；维基百科（独立测试加速比综述）
  • 商业动态：DBTA（IBM 2025-05-28 完成收购 DataStax）；TrustRadius（Astra DB 归属 watsonx.data）
  • 中文资料：CSDN/博客中文教程抽样（多为 3.x/4.0 时代内容）
  • 下次评审：跟踪 Cassandra 6.0 GA（Accord/事务性集群元数据）、ScyllaDB 2026.3+ 的 tablets 在线迁移（2026.2 为实验性）与向量搜索自建版状态