综合练习

把本 track 串起来：为「社交图谱 + 内容 + 搜索 + 分析」场景选型，写出主库与 Specialty 组合、CAP 取舍与数据流——目标不是背产品名，而是 可辩护的工程方案。

学习目标

• 独立完成一次多库存架构设计说明（1–2 页）
• 对照 sdb-intro 至 sdb-ops 的检查清单自审
• 衔接 mongodb-essentials、postgresql-essentials、elasticsearch-essentials、scaling-essentials

场景说明

某学习社区产品（类似 CodeRoadMap 社交扩展）需要：

功能	特征
用户、课程、订单	强事务、外键、报表
关注/好友/共同学习	多度关系查询、推荐环检测
动态、评论	高写入、嵌套、schema 演进
站内搜索	全文、标签、高亮
运营大盘	亿级事件、7 日留存、漏斗

约束：团队熟悉 Java/Spring；可运维 2–3 种数据库，不宜超过 5 种；AWS 可选组件。

任务要求

1. 选型表：每个功能块指定引擎（可组合），一句话理由
2. 架构图：ASCII 或 Mermaid，标出 OLTP / 搜索 / OLAP / 图 / 缓存
3. CAP 段落：至少 2 处 explicit trade-off（如搜索延迟、关注列表最终一致）
4. 数据流：主库如何同步到 ES / ClickHouse（CDC 或双写，说明风险）
5. 反模式：列出本场景下你会 拒绝 的一种方案及原因

可参考决策树 sdb-when 与反模式表。

参考解法要点（自评用，先独立完成）

• 主库：PostgreSQL（orm-jpa 实体、订单事务）
• 图谱：Neo4j 存 FOLLOWS / STUDIED_WITH；用户 ID 与 PG 对齐
• UGC：MongoDB 或 PG JSONB（二选一，需论证）
• 搜索：Elasticsearch（es-query 级 DSL）
• 分析：ClickHouse ETL 自 PG + 行为 Kafka
• 缓存/限流：Redis（scale-cache）
• 不必 DynamoDB/Firebase，除非论证 Serverless/移动端直连需求（ddb-intro）

必走流程

1. 独立写选型 doc（Markdown 即可）
2. 对照 sdb-cap：每库写一致性与延迟预期
3. 对照 sdb-ops：每库写 backup 一句
4. 与同伴或未来 PR review 互审：能否被 [scale-practice](/tracks/scaling-essentials/lessons/scale-practice) 级 checklist 挑战

自检清单

• 我能解释 为何不用单一 MongoDB 扛全部
• 我能解释 图库不存订单行项目 的分工
• ES 延迟与 PG 权威的关系已写清
• 至少链接本 track 外 3 个 相关 lesson（postgresql / mongo / es / scaling / orm / dynamodb）
• 方案在 3 种库运维上限 内

反思题

1. 若 Neo4j 运维预算为零，你会如何降级方案？
2. 分区发生时，关注数与搜索哪个可先牺牲可用性？
3. 若迁移现有 MySQL 单库，第一步拆哪张表、为什么？

小结

场景化选型 + CAP + 数据流 + 运维——Specialty 数据库入门的合格交付不过如此。 本 track 完结；深入请分别进入 mongodb、postgresql、elasticsearch、scaling、dynamodb、orm 各 track。