nosql-expert

NoSQL 专家模式（Cassandra 和 DynamoDB）

概览

此技能为分布式宽列存储和键值存储（具体指 Apache Cassandra 和 Amazon DynamoDB）提供专业的思维模型和设计模式。

与 SQL（建模数据实体）或文档存储（如 MongoDB）不同，这些分布式系统要求你先对查询建模。

适用场景

• 面向规模进行设计：从简单的单节点数据库迁移到分布式集群。
• 技术选型：评估或使用 Cassandra、ScyllaDB 或 DynamoDB。
• 性能调优：排查现有 NoSQL 系统中的“热点分区”或高延迟问题。
• 微服务：实现“每个服务一个数据库”模式，以支持高度优化的读取。

思维转变：SQL 与分布式 NoSQL

特性	SQL（关系型）	分布式 NoSQL（Cassandra/DynamoDB）
数据建模	对实体和关系建模	对查询（访问模式）建模
联接	CPU 密集型，在读取时执行	在写入时预先计算（反规范化）
存储成本	昂贵（尽量减少重复）	低廉（通过重复数据提升读取速度）
一致性	ACID（强一致性）	BASE（最终一致性） / 可调
可扩展性	垂直扩展（更强大的机器）	水平扩展（更多节点/分片）

黄金法则： 在 SQL 中，你设计数据模型来回答任意查询。在 NoSQL 中，你设计数据模型来高效地回答特定查询。

核心设计模式

1. 查询优先建模（访问模式）

通常，你无法在不进行迁移或创建新表/索引的情况下“事后添加查询”。

流程：

1. 列出所有实体（用户、订单、产品）。
2. 列出所有访问模式（“按电子邮件查找用户”“按日期排序，查找用户的订单”）。
3. 设计表，专门服务于这些模式，并通过单次查找完成查询。

2. 分区键至关重要

数据会根据**分区键（PK）**分布到物理节点上。

• 目标： 均匀分布数据和流量。
• 反模式： 使用低基数 PK（例如 status="active" 或 gender="m"）会造成热点分区，使吞吐量受限于单个节点的处理能力。
• 最佳实践： 使用高基数键（用户 ID、设备 ID、复合键）。

3. 聚类键 / 排序键

在一个分区内，数据会根据**聚类键（Cassandra）或排序键（DynamoDB）**在磁盘上排序。

• 这支持高效的范围查询（例如 WHERE user_id=X AND date > Y）。
• 它能根据特定的检索需求，预先对数据排序。

4. 单表设计（邻接列表）

主要用途：DynamoDB（但相关概念也适用于其他系统）

将多种实体类型存储在一个表中，从而支持读取预联接的数据。

PK（分区键）	SK（排序键）	数据字段……
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"
• 结果： 通过一次网络请求获取用户档案和所有订单。

5. 反规范化与数据重复

不必担心在多个表中存储相同的数据，以支持不同的查询模式。

• 表 A： users_by_id（PK：uuid）
• 表 B： users_by_email（PK：email）

权衡：你必须管理表之间的数据一致性（通常使用最终一致性或批量写入）。

具体指南

Apache Cassandra / ScyllaDB

• 主键结构： ((Partition Key), Clustering Columns)
• 不支持联接和聚合： 不要尝试使用 JOIN 或 GROUP BY。请在单独的计数器表中预先计算聚合结果。
• 避免使用 ALLOW FILTERING： 如果在生产环境中看到它，就说明数据模型有问题。这意味着要扫描整个集群。
• 写入开销低： 插入和更新只是追加到 LSM 树中。相比写入量，更应关注读取效率。
• 墓碑： 删除会产生开销较大的标记。请避免在标准表中采用高频删除模式（例如队列）。

AWS DynamoDB

• GSI（全局二级索引）： 使用 GSI 创建数据的其他视图（例如，按日期而非用户搜索订单）。
  • 注意： GSI 的一致性是最终一致的。
• LSI（本地二级索引）： 在同一分区内以不同方式对数据排序。必须在创建表时创建。
• WCU / RCU： 了解容量模式。单表设计有助于优化消耗的容量单位。
• TTL： 使用生存时间属性自动过期旧数据（免费删除），无需创建墓碑。

专家检查清单

确定 NoSQL 架构前：

• 访问模式覆盖： 每种查询模式是否都对应到特定表或索引？
• 基数检查： 分区键是否有足够多的唯一值，以便均匀分散流量？
• 分区拆分风险： 对于任何单个分区（例如，单个用户的订单），数据是否会无限增长？（如果超过 10GB，就需要对分区进行“分片”，例如 USER#123#2024-01）。
• 一致性要求： 对于这种读取模式，应用程序能否容忍最终一致性？

常见反模式

❌ 散点聚合： 查询所有分区以查找单个项目（扫描）。 ❌ 热点键： 将所有“星期一”的数据放入一个分区。 ❌ 关系型建模： 创建 Author 和 Book 表，并尝试在代码中联接它们。（应改为将 Book 摘要嵌入 Author，或在 Books 中重复存储 Author 信息）。