宽列数据库入门：Cassandra 与 ScyllaDB

一个视频，讲透宽列数据库，不用学几个月。

第一章 - 宽列数据库是什么

这一个视频把宽列数据库这一类讲完，重点对比两个代表：{{Cassandra}} 和 {{ScyllaDB}}。

一句话：宽列数据库是面向{{海量写入和水平扩展}}的分布式数据库，用{{行键 + 列族}}组织数据，牺牲复杂查询换来无限扩展。

先澄清：宽列不是列式存储

宽列（Wide-Column）和列式存储（Columnar，如 ClickHouse）是两码事。宽列是用 {{Row Key}} 找到一个分区，再在 {{Column Family}} 里放一堆稀疏列。

宽列: row key -> 分区 -> 一堆稀疏列（适合写入扩展）
列式: 按列存整列数据（适合分析聚合）

这一类数据库的共同点

• 天生分布式，多节点对等，没有单点。
• 为写入和水平扩展优化，适合时序、日志、海量事件。
• 没有 JOIN，查询必须带分区键。

本章小结

宽列数据库求的是"写得多、扩得开"，Cassandra 是鼻祖，ScyllaDB 是更快的高性能实现。

第二章 - 数据模型：分区键 + 列族

三层结构

Keyspace（键空间，一个库）
└─ Table（表）
     └─ Row = 分区键 + 聚类列 + 若干列

分区键和聚类列

{{分区键 Partition Key}} 决定数据存到哪个节点（哈希），{{聚类列 Clustering Column}} 决定分区内怎么排序。

CREATE TABLE orders (
  user_id    uuid,
  order_time timestamp,
  amount     decimal,
  PRIMARY KEY (user_id, order_time)   -- user_id 分区，order_time 排序
);

同一 user_id 的所有订单落进同一个分区，按 order_time 排好

关键约束：查询必须带分区键

不能像 SQL 那样随便 WHERE 任意字段，否则要扫全集群，慢且贵。

本章小结

分区键决定数据在哪、查询能查多快，是宽列建模的第一件事。

第三章 - Cassandra：CQL 与 CRUD

CQL：长得像 SQL，但不是 SQL

{{CQL}}（Cassandra Query Language）语法像 SQL，但没有 JOIN、没有跨分区的事务。

CREATE KEYSPACE shop WITH replication =
  {'class': 'SimpleStrategy', 'replication_factor': 3};

CREATE TABLE users (
  user_id uuid PRIMARY KEY,
  name    text,
  age     int
);

INSERT INTO users (user_id, name, age) VALUES (uuid(), 'Ada', 28);
SELECT * FROM users WHERE user_id = ?;
UPDATE users SET age = 29 WHERE user_id = ?;
DELETE FROM users WHERE user_id = ?;

写是追加，改是覆盖

Cassandra 写入是{{追加式}}的：不原地改，而是写新版本，靠时间戳判谁新。所以写极快。

本章小结

CQL 长得像 SQL，但没有 JOIN；查询必须带主键；写是追加式所以特别快。

第四章 - Cassandra：分区、复制、一致性

无主架构 + 复制

Cassandra 是{{无主}}架构：所有节点对等，数据按分区键哈希分布，每个分区复制 N 份（{{replication factor}}）。

节点1 [分区A 主]  [分区B 副本]
节点2 [分区B 主]  [分区A 副本]
节点3 [分区C 主]  [分区A 副本]

可调一致性：Quorum

读写时可以指定要多少个节点确认，在一致性和可用性之间调：

ONE    ：一个节点确认就行（最快，可能读到旧值）
QUORUM ：多数节点确认（平衡，最常用）
ALL    ：全部节点确认（最强，最慢）

本章小结

无主架构没有单点，复制份数可配，一致性用 ONE/QUORUM/ALL 调——这是 Cassandra 的分布式核心。

第五章 - Cassandra：LSM 树与建模

LSM 树：为什么写这么快

Cassandra 底层用{{LSM 树}}：先写内存（Memtable），满了再刷成磁盘上的 SSTable，后台再合并（Compaction）。

写入 -> Memtable（内存）-> 刷盘 -> SSTable（有序文件）
读   -> Memtable + 多个 SSTable 合并结果
Compaction -> 后台合并 SSTable，清掉旧版本

建模：反范式，按查询建表

没有 JOIN，所以建模时{{按查询来设计}}，宁可冗余，也要让一条查询只命中一个分区。

要"按用户查订单" -> 建 (user_id, order_time) 表
要"按商品查订单" -> 再建一张 (product_id, order_time) 表

本章小结

LSM 树换写入速度，建模按查询反范式——这是 Cassandra 高性能的两大根源。

第六章 - ScyllaDB：Cassandra 兼容 + Shard-per-core

是什么

{{ScyllaDB}} 是 Cassandra 的{{高性能替代品}}，用 C++ 重写，接口、CQL、驱动完全兼容，但吞吐更高、延迟更低。

Shard-per-core 架构

Cassandra 是 Java，靠一个线程池处理；ScyllaDB 给每个 CPU 核分配一个{{分片 shard}}，各自独立跑，几乎没有锁竞争和 GC 停顿。

Cassandra: Java + 线程池（有 GC 停顿）
ScyllaDB:  C++ + 每核一个 shard（无 GC，极致利用多核）

迁移成本极低

因为兼容 Cassandra 的 CQL 和驱动，把连接地址一换就能迁过去，代码几乎不用改。

本章小结

ScyllaDB = 更快更强的 Cassandra：shard-per-core 榨干多核，兼容 CQL 让迁移几乎零成本。

第七章 - Cassandra vs ScyllaDB 对比

一句话选型

新项目追求极致性能选 {{ScyllaDB}}，已有 Cassandra 且够用就继续 {{Cassandra}}。

本章小结

两者 CQL 一样，差别在实现——ScyllaDB 用 C++ 和 shard-per-core 换来了更高的性能天花板。

第八章 - 用 Python 连接两者

同一个驱动：cassandra-driver

from cassandra.cluster import Cluster
from uuid import uuid4

cluster = Cluster(['127.0.0.1'])     # 连 Cassandra 或 ScyllaDB
session = cluster.connect('shop')

session.execute(
    "INSERT INTO users (user_id, name, age) VALUES (%s, %s, %s)",
    (uuid4(), 'Ada', 28)
)
rows = session.execute("SELECT name, age FROM users")
for row in rows:
    print(row.name, row.age)

本章小结

因为 ScyllaDB 兼容 Cassandra，所以用同一个 cassandra-driver 连两者，代码零改动。

第九章 - 什么时候用宽列数据库

适合

• 海量写入、水平扩展（日志、时序、事件、消息）。
• 多数据中心、要高可用、不能有单点。
• 查询模式固定，能按分区键设计。

不适合

• 复杂 JOIN、任意条件查询 -> 关系型。
• 需要强 ACID 事务 -> 关系型。
• 低频但复杂的分析聚合 -> 列式分析库。

本章小结

宽列数据库赢在"写入吞吐和横向扩展"，输在"复杂查询和事务"。

总结

• 核心回顾：宽列数据库用行键 + 列族，为海量写入和水平扩展而生；Cassandra 无主架构 + 可调一致性（ONE/QUORUM/ALL）+ LSM 树；建模按查询反范式；ScyllaDB 用 C++ 和 shard-per-core 做高性能兼容实现，同一个 cassandra-driver 就能连两者。
• 学习路线：先 Docker 起 Cassandra 练 CQL -> 再起 ScyllaDB 对比吞吐 -> 最后各建一张按查询建模的表。
• 推荐练习：① 建一张 (user_id, order_time) 的订单表，跑带分区键的查询；② 用 QUORUM 和 ONE 各读一次，体会一致性差异；③ 同一个 CQL 脚本分别跑在 Cassandra 和 ScyllaDB 上，观察性能。