3. 数据库在风控中的角色：关系型数据库与非关系型数据库的协同
在风控系统中，数据库并非单一存储，而是根据数据特性分层承载不同职责。关系型数据库（MySQL/PostgreSQL）负责存储强一致性、结构化、需事务保障的策略元数据；非关系型数据库（Redis/MongoDB）则负责存储高并发、低延迟、结构灵活的实时特征。两者互补，构成风控系统的数据底座。
3.1 关系型数据库：策略元数据的基石
策略元数据包括规则定义、策略版本、模型配置、黑白名单、用户标签等。这类数据具有以下特征：
- 强一致性：策略的发布与回滚必须原子性完成，不允许出现部分生效。
- 结构化：规则条件、算子、阈值等字段固定，适合用表模式存储。
- 事务性：策略编排涉及多表关联更新，需要 ACID 保障。
| 对比维度 | MySQL (InnoDB) | PostgreSQL |
|---|---|---|
| 事务支持 | 行级锁 + MVCC，适合高并发读写 | MVCC + 快照隔离，支持可序列化隔离级别 |
| JSON 支持 | JSON 类型，索引能力有限 | JSONB 类型，支持 GIN 索引与高效查询 |
| 扩展性 | 主从复制 + 分库分表（需中间件） | 逻辑复制 + 声明式分区，原生支持更完善 |
| 典型场景 | 规则库、黑白名单、标签表 | 策略版本管理、复杂条件表达式存储 |
实践建议：策略元数据表设计时，建议将规则条件与动作拆分为独立子表，通过策略 ID 关联，便于版本对比与灰度发布。
3.2 非关系型数据库：实时特征的加速器
实时特征包括设备指纹、IP 画像、用户行为计数、滑动窗口统计等。这类数据要求：
- 低延迟：单次特征查询需在毫秒级完成，支撑实时决策。
- 高并发：每秒数万甚至数十万次读写。
- 灵活结构：特征字段随业务迭代频繁变化，不适合固定表模式。
| 对比维度 | Redis | MongoDB |
|---|---|---|
| 数据模型 | Key-Value，支持 String/Hash/Set/Sorted Set | 文档型（BSON），支持嵌套与数组 |
| 持久化 | RDB/AOF，主从异步复制 | WAL + 副本集，支持多节点强一致 |
| 查询能力 | 基于 Key 的 O(1) 操作，不支持复杂条件 | 二级索引、聚合管道、地理空间查询 |
| 典型场景 | 计数器、滑动窗口、布隆过滤器、分布式锁 | 设备指纹、用户画像、事件日志 |
注意：Redis 的持久化能力较弱，若用于存储不可丢失的特征数据（如风控判决结果），需配合 AOF 每写一刷或使用 Redis 企业版。MongoDB 在写入量极大时需关注 WiredTiger 引擎的缓存压力。
3.3 数据库选型对比总览
以下表格从风控系统核心关注点出发，对四种数据库进行横向对比：
| 评估维度 | MySQL | PostgreSQL | Redis | MongoDB |
|---|---|---|---|---|
| 数据一致性 | 强（ACID） | 强（ACID） | 最终一致性 | 可配置（强/最终） |
| 读写延迟 | 3-10ms | 3-10ms | <1ms | 2-5ms |
| 并发吞吐 | 万级 QPS | 万级 QPS | 十万级 QPS | 万级 QPS |
| 数据模型灵活性 | 低（固定 Schema） | 中（JSONB 扩展） | 低（Key-Value） | 高（文档嵌套） |
| 运维复杂度 | 中 | 中 | 低 | 中高 |
| 风控适用场景 | 规则库、标签表 | 策略版本、表达式 | 实时计数、缓存 | 设备画像、事件 |
3.4 数据库协同架构
在风控系统中，四种数据库并非孤立部署，而是通过异步任务编排形成数据流转闭环。下图展示了典型的分层协同架构：
3.5 选型决策流程
在实际风控系统设计中，可按以下步骤进行数据库选型：
- 识别数据分类：区分元数据（策略/规则）与特征数据（实时/离线）。
- 评估一致性要求：元数据必须强一致，选 MySQL/PostgreSQL；特征数据可最终一致，选 Redis/MongoDB。
- 评估读写模式：高频简单读写选 Redis；复杂查询与嵌套文档选 MongoDB。
- 评估扩展需求：未来数据量增长是否需分片？PostgreSQL 原生分区优于 MySQL 分库分表。
- 评估运维能力：团队熟悉 MySQL 生态则优先选 MySQL；需要 JSONB 灵活查询则选 PostgreSQL。
核心原则：没有银弹。风控数据库选型的本质是在一致性、延迟、灵活性、运维成本之间做权衡。推荐采用“关系型 + 非关系型”混合架构，通过异步任务编排实现数据同步与解耦。