Files
AIclinicalresearch/docs/08-项目管理/04-技术决策/2025-11-18-阿里云RDS系列选择建议.md
HaHafeng 8eef9e0544 feat(asl): Complete Week 4 - Results display and Excel export with hybrid solution
Features:
- Backend statistics API (cloud-native Prisma aggregation)
- Results page with hybrid solution (AI consensus + human final decision)
- Excel export (frontend generation, zero disk write, cloud-native)
- PRISMA-style exclusion reason analysis with bar chart
- Batch selection and export (3 export methods)
- Fixed logic contradiction (inclusion does not show exclusion reason)
- Optimized table width (870px, no horizontal scroll)

Components:
- Backend: screeningController.ts - add getProjectStatistics API
- Frontend: ScreeningResults.tsx - complete results page (hybrid solution)
- Frontend: excelExport.ts - Excel export utility (40 columns full info)
- Frontend: ScreeningWorkbench.tsx - add navigation button
- Utils: get-test-projects.mjs - quick test tool

Architecture:
- Cloud-native: backend aggregation reduces network transfer
- Cloud-native: frontend Excel generation (zero file persistence)
- Reuse platform: global prisma instance, logger
- Performance: statistics API < 500ms, Excel export < 3s (1000 records)

Documentation:
- Update module status guide (add Week 4 features)
- Update task breakdown (mark Week 4 completed)
- Update API design spec (add statistics API)
- Update database design (add field usage notes)
- Create Week 4 development plan
- Create Week 4 completion report
- Create technical debt list

Test:
- End-to-end flow test passed
- All features verified
- Performance test passed
- Cloud-native compliance verified

Ref: Week 4 Development Plan
Scope: ASL Module MVP - Title Abstract Screening Results
Cloud-Native: Backend aggregation + Frontend Excel generation
2025-11-21 20:12:38 +08:00

19 KiB
Raw Blame History

阿里云RDS PostgreSQL系列选择建议

分析日期: 2025-11-18
项目阶段: 创业初期ASL模块待开发
问题: 需要购买"高可用系列"吗?还是"基础系列"就够?
结论: 创业初期使用"基础系列"6个月后视流量增长考虑升级


📊 阿里云RDS PostgreSQL 三个系列对比

基础系列(推荐创业初期)

架构特点:

┌─────────────────┐
│  单节点实例      │  ← 计算与存储分离
│  (Primary)      │
└─────────────────┘
        ↓
  云盘存储(独立)

核心特性:

  • 单节点,计算与存储分离
  • 不支持增加只读实例
  • 不支持自动故障切换
  • 支持手动备份和恢复
  • 支持数据恢复到指定时间点PITR

适用场景(官方):

  • 个人学习
  • 微型网站
  • 中小企业的开发测试环境 ← 您在这

价格(估算):

最小配置1核2GB
- 按量付费:~¥0.5/小时 = ~¥360/月
- 包年包月:~¥300/月

推荐配置2核4GB
- 按量付费:~¥1/小时 = ~¥720/月
- 包年包月:~¥600/月

高可用系列(中等规模)

架构特点:

┌─────────────────┐      ┌─────────────────┐
│  主节点          │ ───→ │  备节点          │  ← 自动切换
│  (Primary)      │      │  (Standby)      │
└─────────────────┘      └─────────────────┘
        ↓                        ↓
    云盘存储                  云盘存储
        ↓
  ┌─────────────────┐
  │  只读实例(可选) │  ← 可扩展读能力
  └─────────────────┘

核心特性:

  • 一主一备的高可用架构
  • 支持自动故障切换30-60秒
  • 备节点不可访问(仅用于故障切换)
  • 支持增加只读实例扩展读能力
  • 支持高级备份和恢复

适用场景(官方):

  • 大中型企业的生产数据库
  • 互联网、物联网
  • 零售电商、物流、游戏

价格(估算):

最小配置1核2GB
- 按量付费:~¥1/小时 = ~¥720/月
- 包年包月:~¥600/月

推荐配置2核4GB
- 按量付费:~¥2/小时 = ~¥1,440/月
- 包年包月:~¥1,200/月

价格约为基础系列的2倍 ⚠️

集群系列(大规模)

架构特点:

┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
│  主节点          │ ───→ │  备节点1可读  │ ───→ │  备节点2可读  │
│  (Primary)      │      │  (Standby)      │      │  (Standby)      │
└─────────────────┘      └─────────────────┘      └─────────────────┘
      ↓                         ↓                         ↓
    云盘                      云盘                       云盘

核心特性:

  • 一主多备的高可用架构
  • 备节点可访问(提升读能力)
  • 支持自动故障切换
  • 支持增加更多备节点

适用场景(官方):

  • 互联网新零售行业
  • 汽车制造行业
  • 企业大型ERP系统

价格(估算):

最小配置:~¥2,000/月起
推荐配置:~¥5,000/月起

价格约为基础系列的3-5倍 ⚠️⚠️

💰 成本对比分析

创业初期成本预算

基础系列(推荐):

2核4GB配置
- 包年包月¥600/月
- 年成本:   ¥7,200

特点:单节点,成本最低 ✅

高可用系列:

2核4GB配置
- 包年包月¥1,200/月
- 年成本:   ¥14,400

多花费¥7,200/年600元/月)⚠️

集群系列:

最小配置:
- 包年包月¥2,000/月起
- 年成本:   ¥24,000起

多花费¥16,800/年1,400元/月)⚠️⚠️

成本对比总结

系列 月成本 年成本 vs基础系列
基础系列 ¥600 ¥7,200 基准
高可用系列 ¥1,200 ¥14,400 多¥7,200/年
集群系列 ¥2,000+ ¥24,000+ 多¥16,800/年

创业初期成本优先级:

优先投入LLM API调用核心业务
次要投入服务器资源SAE + RDS
可延后:  高可用架构(流量小时非必需)

🎯 需求分析:您需要高可用吗?

高可用系列的核心价值

自动故障切换30-60秒恢复

场景:主节点故障
基础系列手动恢复可能需要30-60分钟 ⚠️
高可用系列自动切换到备节点30-60秒恢复 ✅

问题您的业务能接受30-60分钟的故障恢复时间吗

您的实际情况分析

1. 流量规模

您的预期(创业初期):

日活用户:  <1,000人
并发请求:  <100
高峰QPS   <50

实际影响:
- 故障影响用户数:<100人同时在线
- 故障时长30-60分钟基础系列手动恢复
- 影响范围:小

高可用的价值:

高可用系列故障恢复30-60秒
基础系列故障恢复:  30-60分钟

差异30分钟左右
影响:创业初期流量小,影响可控 ⚠️

多花¥600/月值得吗?见仁见智

2. 业务连续性要求

您的业务特点:

业务类型:医学文献筛选(非实时交易)
数据敏感度:高(但故障不会丢失数据)
业务连续性:重要,但非关键

对比:
- 电商交易1分钟故障 = 损失订单 → 必须高可用 ⭐⭐⭐
- 游戏:     1分钟故障 = 用户流失 → 必须高可用 ⭐⭐⭐
- 文献筛选: 30分钟故障 = 延迟处理 → 可接受 ⚠️

结论:您的业务可以接受短暂故障

3. 故障概率

阿里云RDS故障率SLA

基础系列:
- 可用性99.5%(官方未明确标注)
- 月故障时间约3.6小时/月

高可用系列:
- 可用性99.95%
- 月故障时间约21.6分钟/月

实际概率:
- 基础系列故障约1-2次/年每次30-60分钟
- 高可用系列故障约0-1次/年每次30-60秒

创业初期(日活<1000
1-2次/年的短暂故障 → 影响可控

4. 数据安全性

重要澄清: 基础系列也很安全!

数据安全(两个系列都有保障):
- ✅ 云盘存储(三副本)
- ✅ 自动备份(每天)
- ✅ 时间点恢复PITR
- ✅ 数据加密

故障影响:
- 基础系列服务中断30-60分钟数据不丢失 ✅
- 高可用系列服务中断30-60秒数据不丢失 ✅

结论:两者数据安全性相同,区别只是恢复时间

💡 决策分析

推荐方案:创业初期使用基础系列

理由7条

1. 成本节省显著

基础系列¥600/月 = ¥7,200/年
高可用系列¥1,200/月 = ¥14,400/年

节省¥600/月 = ¥7,200/年

建议:把节省的钱投入到:
- LLM API调用核心业务
- 市场推广(获取用户)
- 产品优化(提升体验)

2. 流量规模小

您的预期流量(创业初期):
- 日活:   <1,000人
- 并发:   <100
- 高峰QPS<50

基础系列能力:
- 支持并发1000+
- 支持QPS 500+2核4GB

结论:基础系列性能完全够用 ✅

3. 故障影响可控

假设场景:数据库故障(概率低)

基础系列:
- 恢复时间30-60分钟
- 影响用户:<100人同时在线
- 数据丢失:无(有备份)
- 业务影响:延迟处理文献筛选

高可用系列:
- 恢复时间30-60秒
- 影响用户:<100人
- 数据丢失:无
- 业务影响:几乎无感知

差异恢复时间差30分钟
创业初期可接受¥600/月的成本 vs 30分钟故障

4. 数据已有保障

基础系列的数据保护:
✅ 云盘三副本存储(硬件故障不丢数据)
✅ 自动每日备份7天保留
✅ 时间点恢复PITR
✅ 手动备份(随时可备份)

结论:数据安全有保障,不会丢失 ✅

5. 您有SAE多实例

您的架构优势:
┌──────────┐   ┌──────────┐   ┌──────────┐
│ SAE实例1 │   │ SAE实例2 │   │ SAE实例3 │  ← 应用层高可用 ✅
└──────────┘   └──────────┘   └──────────┘
       ↓              ↓              ↓
            ┌──────────────┐
            │  RDS基础系列  │  ← 数据库层单节点
            └──────────────┘

特点:
- 应用层已实现高可用SAE自动扩缩容
- 数据库故障时,应用层会自动重连
- 对用户影响:返回错误提示,但不会崩溃

结论:应用层的高可用已经提供了一定的容错能力

6. 可后续平滑升级

现在(创业初期):
基础系列¥600/月)

6个月后流量增长
可升级到高可用系列(阿里云支持在线升级)

升级方式:
1. 控制台点击"变更配置"
2. 选择"高可用系列"
3. 升级过程5-10分钟
4. 数据不丢失

结论:可以随时升级,无需一开始就买高可用 ✅

7. 创业公司的实际情况

创业初期痛点:
- 资金有限每月¥600很重要
- 用户量少(故障影响小)
- 业务迭代快(稳定性优先级中等)

投资优先级:
1. 核心业务开发ASL模块
2. LLM API成本核心功能
3. 市场推广(获取用户)
4. 基础服务器SAE + RDS基础版
5. 高可用架构(可延后)

结论:创业初期不需要高可用

📋 详细对比表

维度 基础系列 高可用系列 您需要吗
价格 ¥600/月 ¥1,200/月 省钱优先
性能 满足并发<100 满足并发<1000 基础够用
自动故障切换 无(手动恢复) 30-60秒 可接受 ⚠️
数据安全 三副本+备份 三副本+备份 都有保障
只读实例 不支持 支持 暂不需要
故障影响 30-60分钟 30-60秒 可接受 ⚠️
升级能力 可升级到高可用 - 可后续升级
创业初期适用 完美 ⚠️ 成本高 基础系列

🎯 决策建议(按阶段)

Phase 1创业初期现在-6个月 当前

推荐:基础系列

配置建议:

系列:基础系列
规格2核4GB起步
存储100GB SSD
版本PostgreSQL 15
付费方式:按量付费(灵活)

月成本:~¥600-720

理由:

  1. 成本最低节省¥600/月)
  2. 性能足够支持并发100+
  3. 数据安全(三副本+备份)
  4. 可后续升级

适用条件:

  • 日活<1,000人
  • 并发<100
  • 每月故障1-2次可接受概率低
  • 30-60分钟恢复时间可接受

Phase 2快速增长期6个月-1年

推荐:评估后决定 ⚠️

升级触发条件满足2条即升级

1. ✅ 日活用户 > 5,000人
2. ✅ 并发请求 > 300
3. ✅ 出现过1次数据库故障影响严重
4. ✅ 业务连续性要求提高不能接受30分钟故障
5. ✅ 营收稳定可承担额外¥600/月)
6. ✅ 需要只读实例(读写分离)

如果满足 → 升级到高可用系列

升级方式:

控制台操作5分钟
1. 登录阿里云RDS控制台
2. 选择实例 → 变更配置
3. 系列:基础系列 → 高可用系列
4. 确认升级5-10分钟短暂中断

数据:不丢失 ✅
配置:自动迁移 ✅

Phase 3成熟期1年+

推荐:高可用系列或集群系列

升级到高可用的条件:

1. ✅ 日活用户 > 10,000人
2. ✅ 并发请求 > 500
3. ✅ 业务不能接受任何故障
4. ✅ 年营收 > 500万成本可承受

升级到集群系列的条件:

1. ✅ 日活用户 > 50,000人
2. ✅ 读写比例 > 5:1读多写少
3. ✅ 需要多个只读实例
4. ✅ 年营收 > 2000万

💡 风险分析

使用基础系列的风险

风险1单点故障

风险描述:

主节点故障 → 手动恢复30-60分钟→ 业务中断

概率评估:

阿里云RDS故障率<0.5%(非常低)
预计故障频率1-2次/年
每次影响时间30-60分钟

年累计故障时间1-2小时/年

影响评估:

创业初期(日活<1000
- 影响用户数:<100人
- 业务损失:延迟处理文献筛选
- 用户流失:极低(医学用户理解力强)

成熟期(日活>10000
- 影响用户数1000+人
- 业务损失:严重
- 用户流失:高
→ 此时必须升级到高可用 ⭐

风险等级: ⚠️ 低(创业初期可接受)


风险2性能瓶颈

风险描述:

流量突然爆发 → 单节点性能不足 → 响应变慢

缓解措施:

1. ✅ SAE自动扩缩容应用层分担压力
2. ✅ 数据库连接池优化(已实现)
3. ✅ Redis缓存减少DB查询
4. ✅ 阿里云RDS支持在线升级规格

临时方案升级RDS规格2核 → 4核5分钟完成
长期方案:升级到高可用系列

风险等级: ⚠️ 低(有缓解措施)


使用基础系列的保障

数据保障(完全够用):

1. ✅ 云盘三副本(硬件故障不丢数据)
2. ✅ 自动每日备份7天保留期
3. ✅ 手动备份(随时可备份)
4. ✅ 时间点恢复PITR可恢复到任意时间点
5. ✅ 异地备份(可选,额外配置)

结论:即使发生故障,数据也不会丢失 ✅

📊 决策矩阵

选择基础系列的条件(您满足所有)

  • 日活用户 < 5,000人
  • 并发请求 < 300
  • 月营收 < 50万
  • 可接受30-60分钟的故障恢复时间
  • 业务非实时交易类型
  • 成本敏感(创业初期)

满足4条以上 → 选择基础系列


选择高可用系列的条件(您不满足)

  • 日活用户 > 5,000人
  • 并发请求 > 300
  • 月营收 > 50万
  • 不能接受任何故障(金融、交易类)
  • 需要只读实例(读写分离)
  • 成本不敏感

满足4条以上 → 选择高可用系列


🎬 行动建议

创业初期(现在-6个月

推荐配置:

系列:     基础系列 ⭐
版本:     PostgreSQL 15
规格:     2核4GB起步
存储:     100GB SSD可扩容
付费方式: 按量付费(灵活,按小时计费)

预估成本: ¥600-720/月

优势:

  • 成本最低
  • 性能足够
  • 灵活调整
  • 可随时升级

风险缓解:

1. 定期备份(每天自动+每周手动)
2. 监控告警(数据库连接数、慢查询)
3. 应急预案(故障时的用户沟通话术)
4. 本地开发环境保持可用(紧急时可切换)

📅 6个月后评估2025年5月

评估升级到高可用系列的条件:

满足以下2条即升级

1. ✅ 日活用户 > 3,000人
2. ✅ 出现过1次故障影响>500人
3. ✅ 月营收 > 30万成本可承受
4. ✅ 客户投诉故障问题
5. ✅ 竞争对手有高可用保障

评估结果:
- 满足 → 升级到高可用系列¥1,200/月)
- 不满足 → 继续使用基础系列

📅 1年后评估2026年

评估升级到集群系列的条件:

满足以下3条即升级

1. ✅ 日活用户 > 50,000人
2. ✅ 并发请求 > 1,000
3. ✅ 读写比例 > 5:1读多写少
4. ✅ 需要多地域部署
5. ✅ 年营收 > 1,000万

评估结果:
- 满足 → 升级到集群系列¥2,000+/月)
- 不满足 → 保持高可用系列

💼 给决策者的明确答案

Q我需要购买高可用系列吗

A不需要创业初期使用基础系列即可


核心理由3条

1. 成本节省

基础系列¥600/月
高可用:  ¥1,200/月

节省¥600/月 = ¥7,200/年

这笔钱可以:
- 购买15,000次DeepSeek调用筛选1,500篇文献
- 或购买120次GPT-4o调用高质量筛选
- 或投入市场推广

创业初期:每一分钱都要花在刀刃上

2. 风险可控

故障概率1-2次/年(低)
恢复时间30-60分钟
影响用户:<100人同时在线
数据丢失:无(有备份保障)

创业初期:可接受 ✅

3. 可随时升级

现在:基础系列(节省成本)
6个月后评估是否需要高可用
→ 如果需要在线升级5-10分钟

结论:不需要一开始就买高可用

📊 最终建议总结

推荐方案(分阶段)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 1: 创业初期0-6个月← 您在这

配置:基础系列 + 2核4GB + 100GB
成本¥600/月
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 2: 快速增长6个月-1年

条件:日活>3000 或 出现故障影响>500人
升级:高可用系列 + 4核8GB
成本¥2,000/月
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 3: 成熟期1年+

条件:日活>50000 或 读写分离需求
升级:集群系列 + 8核16GB
成本¥5,000/月起
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💰 成本对比(年度预算)

阶段 方案 年成本 说明
创业初期 基础系列 ¥7,200 节省¥7,200
如果买高可用 高可用系列 ¥14,400 多花¥7,200
节省金额 - ¥7,200 可投入核心业务

🎉 一句话总结

创业初期使用RDS基础系列即可¥600/月它性能足够、数据安全有保障、可后续平滑升级到高可用每年节省¥7,200成本可投入到LLM调用和市场推广。建议6个月后根据流量增长再评估是否需要高可用。


文档路径: docs/08-项目管理/04-技术决策/2025-11-18-阿里云RDS系列选择建议.md
决策结论: 创业初期使用基础系列6个月后评估升级
推荐配置: 基础系列 + PostgreSQL 15 + 2核4GB + 100GB
复评时间: 2025年5月或日活突破3,000人时
维护者: 技术团队