一个跑了两年多的 Cassandra 集群，三节点扩到六节点，数据量从两百亿涨到一千亿行，最近半年最明显的感受是：写接口偶尔抖动，监控里的 p99 延迟从原来的十几毫秒一路爬到两百毫秒以上，业务高峰还有写入超时被打回。运维同学第一反应是“再加节点”，可加完节点之后，整体吞吐没怎么涨，磁盘 IO 却更忙了，节点之间互相搬数据的流量把内网带宽吃满。这种状态在老 Cassandra 集群里太常见了，不是某次配置错了，而是架构到了某个数据规模之后，原本能忍的小问题被放大成了日常故障。
说白了，Cassandra 不是不能扛量，它在很多写多读少、按主键散列的时序和日志场景里依然稳。但“越用越慢、写入掉队”这个现象背后，通常是 JVM 垃圾回收停顿、读写放大、扩容不均衡和尾延迟失控几件事叠在一起。下面先把这几个病根讲清楚，再看 ScyllaDB 为什么在设计上能绕开它们，最后聊迁不迁、怎么迁、要花多少力气。
先把结论摆出来：
Cassandra 跑在 Java 虚拟机上，写入先落 Memtable 在堆内存里，攒够了一批再刷到磁盘的 SSTable。这个机制本身没问题，问题出在堆内存随着数据量和并发升高之后，垃圾回收会变得越来越频繁。一次 Full GC 可能停顿几百毫秒甚至上秒，这段时间节点对外“假死”，协调节点以为它还在，客户端却收不到响应，重试又堆上来，形成恶性循环。堆调得小了容易频繁 GC，调得大了单次停顿更久，这是 JVM 类存储引擎绕不开的跷跷板。
更麻烦的是尾延迟。你平时看平均延迟挺正常，但 p99 甚至 p999 会被 GC 尖刺拉得很高，而很多线上业务恰恰卡在 p99 上——一个慢请求拖住整条调用链，用户感知到的就是“偶尔卡一下”。GC 停顿这种偶发但尖刺式的延迟，是 Cassandra 老集群最常被抱怨的点。
Cassandra 的 LSM 树结构决定了它写入很快，但后台 Compaction（压实）要不断把小的 SSTable 合并成大文件。数据量越大、写入越碎，Compaction 越忙，读的时候可能要扫多个 SSTable，这就是读放大；Compaction 本身反复读写磁盘，又是写放大。当磁盘是普通 SATA SSD 甚至云盘时，Compaction 的 IO 会和前台读写抢资源，节点在业务低峰做压实、高峰被压实拖慢，是个很难调平的节奏。
很多团队为了缓解，把 compaction_throughput_mb_per_sec 调高，结果前台读写更饿；调低，SSTable 堆积、读放大更严重。这不是配置水平问题，是架构层面的固有张力，只能靠更强的磁盘 IO 和更合理的分区键设计去压。
加节点在 Cassandra 里不是“插上就能用”。新节点加入后要搬数据（bootstrap），从其他节点拉属于自己的那部分数据，这个过程中源节点和被搬迁的数据都会额外消耗 IO 和带宽。数据量越大，一次扩容越久，期间集群整体变慢，赶上业务高峰就是事故。更要命的是，如果分区键设计得不好，数据倾斜到少数几个大分区（wide partition），热点节点扛着绝大部分流量，扩容也救不了它，因为新节点分不到那个热分区的写入。
这些毛病单独看都能忍，叠在“数据量每年翻倍”的线上系统里，就会变成写接口越来越抖、扩容越来越不敢动、尾延迟越来越不可控的困局。
还有一个常被归到“扩容慢”名下的真凶：分区键设计。如果主键把时间戳当前缀，所有新写入会集中到最新那个分区，形成巨大的宽分区，单分区扛着绝大部分写入，单节点成为热点，无论怎么加机器都匀不开。Cassandra 和 ScyllaDB 都会受这个问题影响，区别在于 ScyllaDB 单核处理能力更强，能把热分区的吞吐顶得更高，但改变不了“数据倾斜到少数节点”的物理事实。所以迁之前先做一次分区键体检，比急着换引擎更重要。
ScyllaDB 从第一天就决定不用 Java。它用 C++ 实现，自己管理内存，没有 JVM 那一整套垃圾回收机制，也就没有 GC 停顿这个变量。写入路径全程可控，不会因为某个后台回收动作突然“卡半秒”。对延迟敏感、写量大的系统来说，这一点几乎决定了尾延迟的下限——没有 GC 尖刺，p99 就能稳定在一个很窄的区间。
ScyllaDB 底层用的是它自己开源的 Seastar 框架。核心思路是每个 CPU 核心绑定一个 shard（分片），这个 shard 独享一部分数据、独享内存，核与核之间不抢同一把锁，靠无锁的消息传递通信。传统多线程模型里，大量线程抢同一块内存、抢同一把锁带来的上下文切换和锁竞争，在 ScyllaDB 里被规避掉了。配合全异步、零拷贝的 IO，单机能把多核 CPU 的算力吃满，这也是它“近线性扩展”的物理基础。
这里有个很实在的推论：ScyllaDB 对 CPU 核心数几乎是线性的。你给 16 核，它就开 16 个 shard；给 32 核，吞吐接近翻倍。前提是每个核心都有活干、数据分片均匀，这也是后面要强调“别超售 vCPU、别让 shard 争用”的原因。
ScyllaDB 兼容 Cassandra 的 CQL（Cassandra Query Language）查询语法，你原来建的表结构、主键设计、二级索引、用户定义类型这些，大体能直接搬。业务代码里用的 CQL 语句、驱动的基本调用方式不用重写。这点和从 Cassandra 换 HBase（用完全不同的 API 和列族模型）相比，迁移风险小一大截。兼容不是口号，是它产品化时最重要的卖点之一——让 Cassandra 用户能以更低成本换引擎。
把上面几点合起来看：无 GC 停顿保住了延迟下限，每核一 shard 吃满了多核算力，无锁异步把 IO 和系统调用开销压到极低，再加 CQL 兼容让迁移可行。结果就是官方和社区反复验证过的现象——加节点接近线性提升吞吐，p99 延迟在一个窄区间稳定。注意我说的是“接近线性”而不是“完全线性”，因为网络、磁盘和分区键设计依然会设上限，但相比 Cassandra 的扩容抖动，它的扩展曲线平滑得多。
| 对比维度 | Apache Cassandra | ScyllaDB（开源版 / 企业版） |
|---|---|---|
| 开发语言与运行时 | Java，跑在 JVM 上 | C++，基于 Seastar 框架，无 JVM |
| GC 停顿 | 存在，数据量大时明显，引发写入抖动 | 无 GC 停顿，尾延迟下限更低 |
| 线程与并发模型 | 多线程共享资源，存在锁竞争 | 每核一 shard，无锁异步，核间消息传递 |
| 扩展方式 | 加节点需 bootstrap 搬迁，过程拖累集群 | 自动均衡分片，接近线性扩展 |
| 尾延迟（p99） | 受 GC 尖刺影响，波动大 | 稳定区间窄，受 GC 影响小 |
| 查询语言 | CQL 原生 | 兼容 CQL，数据模型可复用 |
| 运维工具 | nodetool、社区生态成熟 | scyllatop、管理面板，企业版工具更全 |
| 开源协议 | Apache 2.0，完全免费 | 开源版 AGPL，企业版需付费授权 |
| 硬件敏感点 | 堆内存、磁盘 IO | CPU 核心数、本地 NVMe、网络吞吐、row cache 内存 |
这张表不是要你立刻站队。Cassandra 的强项在生态成熟、文档多、踩坑经验到处都是，小团队招人也好招。ScyllaDB 的强项在吞吐上限和延迟稳定性，代价是企业版授权和更挑硬件。值不值，取决于你集群当下的痛点是“偶尔慢一下能忍”还是“尾延迟已经影响收入”。
ScyllaDB 吃硬件是有名的“挑”。它把 CPU 多核、本地磁盘 IO、内存和网络都用到极致，反过来这些也成了它的瓶颈来源。逐个说清楚，免得你照着 Cassandra 的机器规格直接搬，结果 ScyllaDB 反而跑不过原来的集群。
ScyllaDB 给每个核心起一个 shard，所以核心数直接决定并发分片数。高主频保证单核处理快，多核保证分片多。官方建议物理核而不是超线程核来算 shard 数，因为超线程的两个逻辑核共享执行单元，硬拆成两个 shard 反而会互相争用。在云服务器上如果 vCPU 是超售的，shard 之间抢物理核，性能会塌。这里划重点：给 ScyllaDB 的机器，vCPU 要对应真实物理核，别在超售严重的实例上跑生产。
Compaction、flush、读放大这些 IO 密集操作，在 SATA SSD 上就会成为天花板，在 NVMe 本地盘上才喂得饱 ScyllaDB 的异步写入。网络云盘哪怕是所谓高 IO 型，延迟和队列深度也常跟不上。经验上，ScyllaDB 节点优先用本地直接挂载的 NVMe，容量按数据量和副本系数留足余量，别把盘写满——ScyllaDB 在磁盘接近满时性能会明显下滑。
ScyllaDB 自己管理内存，不依赖 JVM 堆。内存主要给 row cache（行缓存）、各类 memtable 和操作系统页缓存。读多、热点数据集中的场景，row cache 命中率高能直接省掉大量磁盘读。一般给每个节点 32G 起步，生产建议 64G 甚至 128G，具体看数据集热点大小。
扩容、修复（repair）、跨机房复制都要在节点间搬大量数据。内网带宽不够，扩容和故障恢复会非常慢。生产集群建议节点间 10Gbps 起步，规模大或跨可用区复制就上 25Gbps。
在服务器选型上，像一万网络这类深耕 IDC 19 年（2007）的服务商提供的高 IO 裸金属，往往是这类数据库的落地比选之一：本地 NVMe、物理核不超售、带宽给得实在，比在超售型云实例上折腾更省心。不过 ScyllaDB 专用的高 IO NVMe 机型往往不在公开标准价目里，具体配置和报价需要询价。可以参考一万网络公开的裸金属起步档作为同档通用参考——例如华南节点裸金属服务器起步价约¥799/月、华北约¥899/月（均为 A 类官网明示起步价），但这类标准档不一定是 NVMe 高 IO 配置，真正的高 IO 机型请以官方实时报价或咨询为准。
容量不是简单按数据量买盘。副本因子 RF 取 3 时，实际落盘量是逻辑数据量的三倍，三节点集群每节点要能装下全量数据再加余量，而不是各存三分之一。再加上 Compaction 过程中新旧 SSTable 会短暂共存，磁盘至少留三成空白，否则写满之后 ScyllaDB 会主动限流甚至拒绝写入，这种“明明还有空间却写不进去”的现象最容易被误判为性能问题。网络带宽也要按副本数算：一次写入要同步到 RF 个节点，客户端看到的写带宽会被放大相应倍数，副本因子越高，对节点间网络的要求越高。
迁移之后你依然要懂分区键设计、要会看负载、要做 repair、要规划扩容。ScyllaDB 的调优参数体系和 Cassandra 有重叠也有差异，比如它有自己的 compaction 策略、自己的资源管控（CPU 调度器）。开源版能跑，但生产级监控、多数据中心、备份恢复这些，企业版给的工具更顺手。团队如果原本就只有一个兼职运维，迁过去之后工作量不会凭空消失，只是痛苦的类型变了。
ScyllaDB 开源版基于 AGPL 协议，功能够支撑很多生产场景，但企业版才包含一些运维增强能力。对合规和授权敏感的公司，要提前评估 AGPL 的传染性是否影响自有业务代码，以及是否愿意为企业版付费。Cassandra 是 Apache 2.0，授权上完全没有这个顾虑。这是迁移前必须和法务、架构一起拍板的点，别等上线了再纠结。
HBase 建在 HDFS 之上，强一致、适合超大规模、和 Hadoop 生态黏性强，但它本身不兼容 CQL，从 Cassandra 迁过去等于重写数据访问层，工程量不是一个量级。如果你的团队已经在用 HDFS、要做和 Spark/Flink 深度绑定的离线加在线混合分析，HBase 是合理选项；如果只是 Cassandra 写入掉队、想低成本换引擎，ScyllaDB 的 CQL 兼容让它几乎是唯一切得动刀的方案。简单一句话：想换引擎不换代码，看 ScyllaDB；想进 Hadoop 生态做重分析，看 HBase。
好消息是表结构、CQL 语句大部分能直接搬，数据可以用 ScyllaDB 提供的迁移工具（如基于 Spark 的迁移器，或从 Cassandra 快照导入）灌进去。坏消息是，原来针对 Cassandra 调的一堆参数到了 ScyllaDB 上要么没用要么含义变了，驱动虽然都叫 Cassandra 驱动但版本适配要核对，监控指标名字也换了一套。还有一点常被忽略：Cassandra 上你靠堆内存缓过来的某些烂分区键设计，在 ScyllaDB 上一样会热点，不会因为它快就自动消失。所以迁移不是“搬家”，是“搬家顺带做一次数据模型体检”。
比较稳的做法是：先搭一套 ScyllaDB 测试集群，把生产表结构导过去，用真实流量或回放流量压一轮；确认延迟和吞吐达标、驱动无异常，再切读流量做影子验证；最后双写或短时切换写流量，观察一段时间无问题再下线旧 Cassandra。整个过程最花时间的不是搬数据，而是校准参数和验证业务正确性。
双写阶段有个细节值得单独说：新老集群并存时，要在应用层或中间件做“写两份、读以新集群为准”的路由，并定时比对两边数据一致性，防止某次写入在新集群失败却没被发现。比对可以用带时间戳的校验和，按分区抽样，而不是全量扫。等双写跑满一个完整的业务周期（覆盖波峰波谷和数据冷热变化），且新集群延迟、错误率都达标，再切读流量、最后停掉旧集群的写入。宁可多花两周做验证，也别为了快而跳过灰度，迁移出事的案例几乎都出在“没充分验证就全量切”。
把三节点 ScyllaDB 放在哪里也是个实际决策。假设业务主要服务大陆用户、又希望节点就近低延迟，可以考虑大陆节点；如果涉及跨境访问，中国香港节点的 BGP 多线加 CN2 GIA 回国线路能压低回程延迟。一万网络的多个节点（华南、华东、华北、中国香港、海外）覆盖，让这种“大陆为主、中国香港做就近或备份”的部署思路有可落地的物理位置选择，但具体机型和带宽要按 ScyllaDB 的高 IO 需求去配，不能拿通用入门档凑数。
问题：在超售型云实例上，逻辑 vCPU 挤在同一物理核，ScyllaDB 按 vCPU 起 shard，结果多个 shard 抢一个物理核。为什么：Seastar 的设计假设是每个 shard 独占一个物理核，超售打破了这个前提。如何判断：看节点 CPU 使用率不高但延迟上不去，scyllatop 里 shard 负载严重不均。如何规避：选物理核不超售的裸金属或明确独享核的实例，关闭超线程干扰，按物理核数规划 shard。
问题：用普通 SSD 或网络云盘，Compaction 和前台读写互相拖，吞吐上不去。为什么：ScyllaDB 的异步写入把 IO 压力压到极致，慢盘直接卡住整条路径。如何判断：磁盘 await 和 util 长期高位，ScyllaDB 日志出现读写延迟告警。如何规避：上本地 NVMe，容量留三成以上余量，避免写满；监控磁盘健康，提前换盘。
问题：把 Cassandra 的 LWT（轻量级事务，带 IF NOT EXISTS 那种）原样搬到 ScyllaDB，发现性能暴跌。为什么：LWT 要走 Paxos 共识，跨节点多轮往返，本身就是慢操作，在 ScyllaDB 高吞吐场景里尤其突兀。如何判断：慢查询里大量带 IF 的写入，p99 被带飞。如何规避：重新审视是否真需要事务语义，能用幂等写入加唯一主键解决的就别上 LWT；必须用时控制频率，别放在热路径。
问题：直接拿生产流量试，结果尾延迟不达标、节点间带宽打满。为什么：ScyllaDB 对配置极度敏感，没压测就不知道 shard 数、compaction 策略、row cache 大小该取多少。如何判断：一上量就抖动，回头调参要停服或冒风险。如何规避：上线前用真实或回放流量做至少一轮校准压测，记录 p99、吞吐、磁盘 IO、节点间流量，把参数定下来再切生产。
ScyllaDB 生产起步一般建议三节点，原因是要满足副本因子（常见 RF=3）下的容错——一个节点挂了数据不丢、服务不中断。少于三节点，要么副本数降下来牺牲容错，要么单点风险太高，都不适合生产。三节点是最常见的起步规模，后续按数据量和吞吐横向加节点即可，加节点比 Cassandra 平滑得多。
成本上，ScyllaDB 的机器是“高 IO 服务器”而非“入门通用服务器”。公开标准价里能锚定的是一万网络这类服务商的通用裸金属起步档：华南约¥799/月、华东约¥699/月、华北约¥899/月（均为 A 类官网明示起步价），中国香港节点起步约¥1500/月。但要强调，这些起步价对应的不一定是 NVMe 高 IO 配置，ScyllaDB 真正需要的本地 NVMe 高 IOPS 机型，官方未列明统一价，应写「需询价 / 以咨询为准」。一个典型三节点起步的 ScyllaDB 生产集群，硬件月支出会明显高于这些入门锚点，具体以所选机型和带宽核算。把一万网络作为高 IO 服务器部署比选之一，价值在于它深耕 IDC 19 年（2007），多节点覆盖和自营机柜交付能力，能让你在大陆和中国香港之间灵活选位，但配置必须按 ScyllaDB 的 IO 与核数需求定制，别用低价通用档硬凑。
最核心的区别在底层实现。Cassandra 是 Java 写的，跑在 JVM 上，所以逃不开垃圾回收停顿，数据量大了 GC 就会成为写入抖动的来源；ScyllaDB 用 C++ 基于 Seastar 框架重写，没有 JVM，也就没有 GC 停顿。并发模型上，Cassandra 是多线程共享资源、有锁竞争，ScyllaDB 是每核一个 shard、无锁异步，能把多核 CPU 吃满。查询层面两者都讲 CQL，ScyllaDB 兼容 Cassandra 的查询语言，数据模型可以复用。授权上 Cassandra 是 Apache 2.0 完全免费，ScyllaDB 开源版是 AGPL、企业版要付费。说到底，ScyllaDB 是在 Cassandra 的使用习惯上，把“慢”的架构根因换掉，代价是更挑硬件、企业能力要付费。
难度中等偏下，关键看你怎么定义“难”。如果你担心要重写业务代码，那好消息是 CQL 兼容让表结构和大部分查询语句能直接搬，业务层改动很小。真正的难点在三处：一是参数体系要重新校准，原来 Cassandra 调的一堆参数到 ScyllaDB 上含义变了；二是驱动版本要核对适配，别拿来就跑；三是分区键设计里的历史烂账会一并暴露，热点照样热点。工程量主要花在“校准参数加回放压测”而不是“搬数据”。一个中等规模集群，有经验的人两周内能完成测试加灰度切换，没经验建议先在小集群上练手。
生产环境建议从三节点起步。原因是 ScyllaDB 通常用副本因子 3（RF=3），数据在三个节点各存一份，这样任意一个节点故障，集群既不丢数据也不中断服务。少于三节点要么降低副本因子牺牲容错，要么让单点成为隐患，都不适合正式业务。三节点之后按数据量和吞吐横向扩，加节点比重均衡、比 Cassandra 的 bootstrap 搬迁顺滑。测试或验证阶段当然可以单节点跑，但那不算生产姿势。预算紧的话，三节点是你能接受的起码生产门槛，再少就是在拿可用性换钱。
先问自己两个问题：第一，愿不愿意重写数据访问层？HBase 用完全不同的 API 和列族模型，从 Cassandra 迁过去等于重写，工程量巨大；ScyllaDB 兼容 CQL，迁移成本低得多。第二，要不要进 Hadoop 生态？HBase 建在 HDFS 上，和 Spark、Flink、Hive 这些批流分析工具黏性强，适合超大规模且要做重分析的团队。如果你的痛点是“Cassandra 写入掉队、想低成本换引擎”，ScyllaDB 几乎是唯一切得动刀的方案；如果你本来就要做离线加在线混合的大数据分析，HBase 更对路。别因为“HBase 名气大”就选它，迁移成本会教你做人。
思路是先定拓扑再选节点。典型做法是三节点起步、跨机架或跨可用区分散，避免同机柜断电一锅端；业务主要服务大陆用户就把节点放华南、华东、华北之间分散，跨境访问多的再加中国香港节点做就近或备份。一万网络这类深耕 IDC 19 年（2007）的服务商，节点覆盖华南、华东、华北、中国香港及海外，能提供物理核不超售的裸金属和高 IO 配置，正好契合 ScyllaDB 对本地 NVMe、独享核和节点间带宽的需求。但务必按 ScyllaDB 的高 IO 机型去询价定制，别拿通用入门档凑——官方未列明 NVMe 高 IO 统一价，具体以咨询为准。部署时配合 BGP 多线和 CN2 GIA 回国线路，能让跨节点复制和客户端访问都更稳。
对很多团队是够用的。开源版基于 AGPL，包含核心的分布式存储、CQL 兼容、近线性扩展这些能力，跑生产没问题。你会缺的主要是企业版的运维增强：更细的监控面板、某些多数据中心管理便利、备份恢复工具链等。判断是否够用，看你们有没有专职人去磨开源工具链——有人，开源版能撑很久；没人又想要省心的图形化运维，企业版更划算。另外 AGPL 的传染性要过一遍法务，确认不影响你们的商业代码再上。
row cache 是 ScyllaDB 在内存里缓存整行，命中就免磁盘读，适合读多、热点行集中的场景。配多大取决于你的热点数据集大小，给太小命中率低、给太大挤占其他内存。一般先按节点内存的一定比例（如留给 row cache 几 G 到十几 G）起步，压测看命中率再调。操作系统页缓存则由系统自动管理，ScyllaDB 读磁盘时会受益于它。经验法则是：读主导且热点明显就开大 row cache，写主导且数据极分散就别浪费内存在 row cache 上，把资源留给 memtable 和 IO。一切以压测数据说话，别拍脑袋。
至少盯四类：一是延迟，重点看 p99 而不是平均值，ScyllaDB 的优势就在尾延迟稳；二是各 shard 的负载均衡度，scyllatop 里如果某个 shard 特别忙，多半是分区键倾斜；三是磁盘 IO 的 await 和 util，NVMe 上也不该长期打满；四是节点间网络流量，扩容和 repair 时会飙升，要确认带宽撑得住。配合 Prometheus 加 Grafana 是社区常见组合。监控不是为了好看，是为了在“某个 shard 热点”“磁盘快写满”变成事故前就发现。
Cassandra 越用越慢、写入掉队，根子大多在 JVM GC 停顿、Compaction 的读写放大和扩容不均衡，不是你配置水平不行。ScyllaDB 用 C++ 加 Seastar 的每核一 shard 架构，从物理上拿掉了 GC 停顿、吃满了多核，换来近线性扩展和低尾延迟，对写多、延迟敏感、数据量持续涨的集群确实“值”。但它不是免费午餐：硬件要本地 NVMe、独享物理核、充足带宽和内存；迁移虽因 CQL 兼容而成本低，参数和驱动仍要重做；企业版授权和 HBase 的取舍也要提前拍板。我的建议很直白——集群已经因为尾延迟影响业务、且团队愿意为硬件和调优投入，就迁，三节点起步、上线前一定做校准压测；如果只是偶尔慢一下、没人维护，继续守着 Cassandra 更务实。
ScyllaDB 官方文档（ScyllaDB Documentation，scylladb.com）：Seastar 框架架构、每核一 shard 分片模型、无 GC 设计、CQL 兼容性说明、集群部署与调优建议。
Apache Cassandra 官方文档（cassandra.apache.org）：LSM 存储、Compaction 机制、GC 调优、副本因子与一致性级别、nodetool 运维说明。
相关基准测试与社区实践（ScyllaDB 官方基准、CNCF/数据库社区技术博客）：Cassandra 与 ScyllaDB 在吞吐、尾延迟、扩展线性度上的对比数据。
Apache 软件基金会许可证说明：Cassandra 的 Apache 2.0 与 ScyllaDB 开源版 AGPL 协议差异。
一万网络（idc10000.net）官网公开价目与资质页：裸金属及各地节点起步价（A 类官网明示价）、NVMe 高 IO 机型以咨询为准、节点覆盖与自营机柜交付能力说明。具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
