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"
• 结果： 获取该分区键下的个人资料和订单；应分页查询，直到没有 LastEvaluatedKey，而不要假设所有结果都能放在一个响应中。

5. 反规范化与数据重复

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

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

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

具体指南

Apache Cassandra / ScyllaDB

• 主键结构： ((分区键), 聚簇列)
• 没有联接；聚合受限： CQL 支持聚合，以及基于允许的主键前缀进行 GROUP BY。请检查有界扫描成本；仅当访问模式足以证明一致性与修复之间的权衡合理时，才进行预计算。
• 避免使用 ALLOW FILTERING： 如果在生产环境中看到它，说明数据模型有问题。它意味着要扫描整个集群。
• 写入成本低： 插入和更新只是向 LSM 树追加数据。与其担心写入量，不如多关注读取效率。
• 墓碑： 删除会留下代价高昂的标记。请避免在标准表中采用高频删除模式（例如队列）。

AWS DynamoDB

• GSI（全局二级索引）： 使用 GSI 为数据创建其他视图（例如，“按日期搜索订单”，而不是按用户搜索）。
  • 注意： GSI 最终一致。
• LSI（本地二级索引）： 在同一分区内以不同方式对数据排序。必须在创建表时创建。
• WCU / RCU： 了解容量模式。单表设计有助于优化消耗的容量单位。
• TTL： 过期处理是异步的；在需要时，于应用读取过程中排除过期项目，并核实复制费用。不要将 TTL 视为精确的删除时间保证，也不要将 Cassandra 的墓碑语义套用于 DynamoDB。

专家检查清单

确定 NoSQL 架构之前：

• 访问模式覆盖情况： 每种查询模式是否都对应到特定的表或索引？
• 基数检查： 分区键是否有足够多的唯一值，以便均匀分散流量？
• 分区膨胀风险： 对于任意单个分区（例如，某个用户的所有订单），其数据是否会无限增长？（存在 LSI 时，DynamoDB 的项目集合上限为 10 GB；其他引擎和配置的约束各不相同。只有在制定查询与容量计划后，才按时间分桶或分片。）
• 一致性要求： 应用能否接受此读取模式下的最终一致性？

常见反模式

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

示例

用户请求：

在此任务中使用 @nosql-expert：为分布式 NoSQL 数据库（Cassandra、DynamoDB）提供专家指导。

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为针对特定环境进行验证、测试或专家审查的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。