001-为什么选择SQLite作为数据库

属性	说明
状态	已接受
创建日期	2024-05-18
作者	你的名字

背景

在设计ITOps Agent Platform时，我们需要选择一个数据库来存储以下数据：

• 服务器配置和连接信息（加密）
• Agent配置
• 工作流定义
• 任务执行记录
• 告警信息
• 知识库内容
• 用户和权限数据
• 审计日志

选项

我们评估了以下几个选项：

选项1: SQLite

优点：

• 零配置，开箱即用
• 单一文件，方便备份和迁移
• 无需单独的数据库服务进程
• 资源消耗低
• 开发和测试非常方便
• 对于中小规模部署性能足够

缺点：

• 不适合大规模并发写入
• 不适合大数据量（大于100GB）场景
• 不支持真正的客户端/服务器架构
• 缺少一些企业级特性（如复制、集群等）

选项2: PostgreSQL

优点：

• 功能强大，企业级数据库
• 支持并发写入
• 支持大规模数据
• 丰富的生态系统

缺点：

• 需要单独安装和维护
• 配置复杂
• 资源消耗大
• 增加部署复杂度

选项3: MySQL

优点：

• 流行度高
• 社区生态好
• 性能优秀

缺点：

• 同样需要单独部署
• 配置相对复杂
• 增加系统组件

决策

我们选择SQLite作为我们的数据库。

理由

1. 目标用户是中小企业：我们的主要目标用户是中小型企业，他们通常：

   • 服务器规模在几十台到一百台
   • 不会有极端的并发需求
   • 希望部署越简单越好

2. 降低部署门槛：使用SQLite意味着用户只需要运行一个Docker Compose，不需要额外配置数据库，这大大降低了使用门槛。

3. 为未来预留扩展空间：我们设计了数据访问层（DAL），通过Repository模式封装了数据访问，未来如果需要迁移到PostgreSQL或MySQL，只需要重写Repository层，业务逻辑代码不需要改动。

4. SQLite已经足够强大：现代版本的SQLite性能非常优秀，对于我们的场景完全够用：

   • 支持事务
   • 支持并发读取（WAL模式）
   • 支持完整的SQL语法
   • 足够的性能和容量

后果

正面后果

• 部署简单，用户体验好
• 开发和测试方便
• 资源消耗小
• 数据备份简单（只需要复制一个文件）

负面后果

• 不适合超大规模部署
• 不支持读写分离
• 不支持在线热备份（需要加锁或使用WAL模式）

未来计划

我们会监控用户的使用场景和反馈，如果发现确实有企业用户需要更强大的数据库支持，我们会：

1. 提供PostgreSQL作为可选方案
2. 保持SQLite作为默认选项（对小用户友好）
3. 通过配置让用户选择使用哪个数据库
4. 提供从SQLite迁移到PostgreSQL的工具