Nosql distributed db

分布式 NoSQL 数据库专家

domain：数据/misc｜name：nosql-distributed-db｜status：stable agents：claude-code、codex、cursor、gemini-cli｜license：MIT

何时使用

• 设计面向规模的分布式宽列/键值存储：Apache Cassandra、ScyllaDB、Amazon DynamoDB。
• 选型评估：在上述分布式库之间权衡，或判断该不该从单机库迁过来。
• 性能调优：排查既有 NoSQL 系统的「热分区(hot partition)」、高延迟、吞吐打满单节点。
• 微服务「一服务一库」：需要为高度优化的读路径预先建模。

核心心智：SQL 先建实体与关系、读时 JOIN；这类分布式库要查询优先建模——先列出访问模式，再为每个模式设计能一次查中的表/索引。

不该用的边界：

• 关系型库 schema/范式/ERD 设计 → 用 erd-schema-designer，本条不做实体关系建模。
• 写业务查询 SQL（联表/聚合/窗口）→ 用 sql-query-builder。
• MongoDB 等文档库的文档/嵌套建模、单机 Redis/KV 做缓存选型 → 不在本条范围。
• 需要强一致事务、自由 ad-hoc 查询、跨表 JOIN/GROUP BY 的负载 → 这类库不适配，应回到关系型或 OLAP。

步骤

1. 查询优先建模（先模式，后表）
   a. 列全部实体（User / Order / Product）
   b. 列全部访问模式（"按 email 取 User"、"按 User 取 Order 并按日期排序"）
   c. 为每个模式设计能"单次查中"的表/索引——不要指望事后加查询
   注：这类库通常无法"以后再加查询"，加新模式 = 建新表/新索引 + 数据迁移

2. 分区键(PK)定生死——决定数据落在哪个物理节点
   目标：数据与流量均匀分散
   反模式：低基数 PK（status="active"、gender="m"）→ 热分区，吞吐被锁死在单节点
   正解：高基数键（User ID、Device ID、复合键）

3. 聚簇键 / 排序键——分区内磁盘排序
   Cassandra 叫 Clustering Key，DynamoDB 叫 Sort Key
   支持高效范围查询：WHERE user_id=X AND date > Y
   本质是为特定读取需求把数据预排序

4. 单表设计（邻接表，主要 DynamoDB）
   多实体类型塞一张表，PK 相同、SK 区分类型 → 一次网络请求拿全
   例：PK=USER#123 一把捞出 PROFILE + 所有 ORDER#xxx

5. 反范式与冗余——别怕一份数据存多处
   users_by_id（PK=uuid）、users_by_email（PK=email）各建一表
   代价：跨表一致性需自管（最终一致或批量写）

6. 收尾走"专家清单"逐项核对（见下）

指令

判断口诀与硬约束：

• 建模顺序反过来：SQL 让模型回答任意查询；这里让模型高效回答特定查询。
• 写便宜、读为王：LSM 树下 Insert/Update 只是追加，别担心写量，重点优化读效率。
• 存储不值钱：为读速度复制数据是常态，不要为去重而牺牲读路径。
• 一致性可调：BASE / 最终一致是默认；强一致要显式付出代价。

Cassandra / ScyllaDB 专项：

• 主键结构：((Partition Key), Clustering Columns)。
• 无 JOIN、无聚合：聚合预算到单独的 counter 表，别想 JOIN / GROUP BY。
• 禁 ALLOW FILTERING：生产里出现它 = 数据模型错了，它意味着全集群扫描。
• 墓碑(tombstones)：删除是昂贵标记，避免高频删除模式（如把标准表当队列用）。

AWS DynamoDB 专项：

• GSI（全局二级索引）：建数据的「另一种视图」（如「按日期查 Order」而非按 User）。注意 GSI 是最终一致。
• LSI（本地二级索引）：在同一分区内换一种排序，必须建表时创建。
• WCU / RCU：理解容量模式；单表设计有助于优化消耗的容量单元。
• TTL：用 Time-To-Live 属性自动过期旧数据（免费删除），避免产生墓碑。

示例

SQL vs 分布式 NoSQL 心智对照：

维度	SQL（关系型）	分布式 NoSQL（Cassandra/DynamoDB）
建模对象	实体 + 关系	查询（访问模式）
JOIN	读时算，吃 CPU	写时预计算（反范式）
存储成本	贵，尽量去重	便宜，为读速度复制
一致性	ACID（强）	BASE（最终）/ 可调
扩展	垂直（换大机器）	水平（加节点/分片）

黄金法则：SQL 设计模型以回答任意查询；NoSQL 设计模型以高效回答特定查询。

DynamoDB 单表设计（邻接表）——一次请求拿 User + 全部 Order：

PK (Partition) | SK (Sort)   | Data Fields
USER#123       | PROFILE     | { name: "Ian", email: "..." }
USER#123       | ORDER#998   | { total: 50.00, status: "shipped" }
USER#123       | ORDER#999   | { total: 12.00, status: "pending" }

查询：PK = "USER#123"  →  一次网络请求返回 Profile 与所有 Order

专家上线前清单：

[ ] 访问模式覆盖：每个查询模式都映射到某张具体表/索引？
[ ] 基数检查：分区键唯一值是否足够多以均匀分散流量？
[ ] 分区膨胀风险：单分区（如某用户的全部订单）会否无限增长？
                  >10GB 就要"打分区"，如 USER#123#2024-01
[ ] 一致性要求：该读模式能否容忍最终一致？

注意事项

三大反模式（看到就改）：

• ❌ 散播-聚合(Scatter-Gather)：扫所有分区只为找一条（Scan）。
• ❌ 热键(Hot Keys)：把「周一」全部数据塞进一个分区。
• ❌ 关系式建模：建 Author / Book 两表想在代码里 JOIN。改法：把 Book 摘要嵌进 Author，或把 Author 信息复制进 Book。

其他易错点：

• 低基数分区键是最常见性能杀手——上线前务必过「基数检查」。
• 生产出现 ALLOW FILTERING / 全表 Scan 几乎都是建模问题，不要靠加机器硬扛。
• 反范式带来的跨表一致性由你负责，明确「谁负责同步冗余」。
• 本条给的是心智模型与设计模式，不替代环境内的实测、压测与专家评审；缺关键输入（访问模式、规模、一致性要求）时先停下来追问。

互见

• requires：无。
• related：erd-schema-designer —— 关系型一侧的 schema/范式设计，与本条形成「关系 vs 分布式」对照；sql-query-builder —— 关系型查询编写；snowflake-development —— OLAP/数仓侧的数据开发。
• combines_with：data-pipeline-engineer —— 反范式表常由管道写入与回填，组合解决「建模 + 灌数 + 跨表一致性」闭环。

---

本条采编自 sickn33/antigravity-awesome-skills（MIT 许可）。