综合练习
为社交图谱场景选型并说明理由。
40 分钟
综合练习
把本 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 可选组件。
任务要求
- 选型表：每个功能块指定引擎（可组合），一句话理由
- 架构图：ASCII 或 Mermaid，标出 OLTP / 搜索 / OLAP / 图 / 缓存
- CAP 段落：至少 2 处 explicit trade-off（如搜索延迟、关注列表最终一致）
- 数据流：主库如何同步到 ES / ClickHouse（CDC 或双写，说明风险）
- 反模式：列出本场景下你会 拒绝 的一种方案及原因
可参考决策树 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）