数据库选型

经过上一节的分析，我意识到 SQLite 已经无法满足需求。

那一夜，我开始调研替代方案。

数据库分类

┌─────────────────────────────────────────────────────────┐
│                    数据库分类                           │
├─────────────────┬─────────────────┬─────────────────────┤
│   关系型数据库   │   NoSQL 数据库   │    其他数据库       │
├─────────────────┼─────────────────┼─────────────────────┤
│ MySQL           │ MongoDB         │ Redis (缓存)        │
│ PostgreSQL      │ Redis           │ Elasticsearch (搜索)│
│ SQLite          │ Cassandra       │ InfluxDB (时序)     │
│ Oracle          │ DynamoDB        │ Neo4j (图数据库)    │
│ SQL Server      │ Couchbase       │                     │
└─────────────────┴─────────────────┴─────────────────────┘

面对这么多选择，我需要逐一分析。

方案 A：MySQL/PostgreSQL（关系型数据库）

优势

劣势

适合场景

✅ 推荐使用：

• 用户管理系统（数据量不大，查询复杂）
• 订单/支付系统（需要事务保证）
• ERP/CRM 系统（复杂业务逻辑）
• 报表/数据分析（复杂聚合查询）

❌ 不推荐：

• 海量日志存储（考虑 NoSQL）
• 高频写入场景（考虑时序数据库）
• 数据结构频繁变化（考虑文档数据库）

**我的考虑：**用户数据和调用日志需要事务保证，MySQL 是稳妥的选择。

方案 B：MongoDB（文档数据库）

优势

劣势

适合场景

✅ 推荐使用：

• 日志数据（写多读少）
• 内容管理系统（文档结构）
• 物联网数据（Schema 灵活）
• 用户行为追踪

❌ 不推荐：

• 金融系统（需要强事务）
• 复杂关联查询（多表 JOIN）

**我的考虑：**MongoDB 很灵活，但我的数据结构固定，而且需要事务保证。

方案 C：Redis（缓存数据库）

优势

劣势

适合场景

✅ 推荐使用：

• 缓存热点数据
• 计数器（今日调用量）
• 会话存储（Session）
• 消息队列
• 实时排行榜

❌ 不推荐：

• 主数据存储
• 大量历史数据
• 复杂查询需求

**我的考虑：**Redis 不能做主存储，但做缓存再好不过。

方案 D：时序数据库（InfluxDB、TimescaleDB）

优势

劣势

适合场景

✅ 推荐使用：

• 监控数据（CPU、内存使用率）
• 传感器数据（IoT）
• 应用日志
• 金融行情数据

**我的考虑：**时序数据库很专业，但我的日志查询需求不那么特殊，MySQL 就够了。

混合架构

现代应用通常采用多种数据库组合：

┌─────────────────────────────────────────────────────────┐
│                     应用层                               │
└─────────────────┬───────────────────────────────────────┘
                  │
        ┌─────────┼─────────┬──────────────┐
        ▼         ▼         ▼              ▼
   ┌────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐
   │ MySQL  │ │ Redis  │ │ MongoDB  │ │ Elastic- │
   │        │ │        │ │          │ │ search   │
   │ 主数据 │ │ 缓存   │ │ 日志     │ │ 搜索     │
   └────────┘ └────────┘ └──────────┘ └──────────┘

分析完所有选项后，我的决策逻辑逐渐清晰。

我的决策

经过几天的调研，我在白板上画了一个决策矩阵：

最终决定：MySQL + Redis 的混合架构

这个方案的利弊：

✅ 优点：

• MySQL 保证数据一致性和持久化
• Redis 提升热点查询性能
• 技术成熟，学习成本低
• 社区活跃，问题容易解决

⚠️ 挑战：

• 需要维护两种数据库
• 缓存一致性问题需要处理
• 初期架构复杂度增加

但我知道，这是成长的代价。

本节小结

✅ 数据库选型要点：

🎯 下一步：

分析完各种数据库后，我决定采用 MySQL + Redis 的混合方案。

接下来，我要开始迁移实战。