第1章 选型背景与业务约束

本地数据持久化技术选型的第一步，不是翻阅各数据库的特性清单，而是先搞清楚业务场景对持久化层施加了哪些刚性约束。数据规模、读写频率、离线要求、安全合规——这四个维度决定了后续所有技术方案的边界与取舍。任何脱离业务约束的选型，都会在落地阶段暴露出致命缺陷。

1.1 为什么选型必须先看约束

业务场景不会主动告诉你该用 SQLite 还是 RocksDB，但会通过以下方式暴露约束：

• 数据规模：单机存 100 MB 和存 100 GB 的存储引擎选择完全不同；
• 读写频率：写密集型（日志）与读密集型（配置缓存）对索引和维护开销的敏感度迥异；
• 离线要求：纯在线场景可依赖云端同步，弱网或离线场景必须内置本地容错与冲突处理；
• 安全合规：金融级加密与普通应用的数据保护策略在计算开销和接口复杂度上差一个数量级。

四条约束相互耦合：比如高安全加密会降低读写吞吐，大容量离线同步会推高存储成本。只有将四者同时纳入决策框架，才能避免“局部最优，全局不可用”的窘境。

1.2 四大核心约束维度

每个维度需要拆解为可量化的子指标，才能用于后续技术方案对比。下表汇总了四个维度的关键量化参数与选型影响范围：

1.3 约束交叉与权衡矩阵

四个维度并非独立存在，它们之间的相互影响才是选型决策的真正难点。下面用矩阵形式展示最主要的几组权衡关系：

从矩阵可以看出，没有一种持久化技术能同时在所有维度上达到最优。架构师的核心工作是根据业务优先级，在四维空间中定位最优解区域。

1.4 落地第一步：输出约束清单

在进入具体技术评估之前，团队必须产出一份结构化的 约束清单，作为后续所有选型决策的基准参照。清单应包含每个维度的量化指标、来源（业务方/合规/运维）、以及优先级（必选/可选）。

以下是一个可直接用于项目启动的约束清单模板：

# 约束清单模板 v1.0
data_scale:
  total_size: "预估总量: ___ GB/TB"
  growth_rate: "年增长率: ___%"
  record_count: "记录数: ___ 万/亿"
  avg_record_size: "单条平均大小: ___ KB"

read_write_frequency:
  read_write_ratio: "读写比例: ___ : ___"
  peak_qps: "峰值 QPS（读）: ___  |  峰值 QPS（写）: ___"
  latency_sla: "平均时延要求: ___ ms"
  write_pattern: "写入模式: 批量/实时/混合"

offline_requirements:
  max_offline_duration: "最长离线时长: ___ h/d"
  sync_strategy: "同步策略: 全量/增量/按需"
  conflict_resolution: "冲突处理机制: 时间戳/版本号/CRDT/手动"
  network_recovery: "网络恢复后行为: 静默同步/用户确认"

security_compliance:
  encryption_standard: "加密标准: AES-256 / SM4 / 其他"
  key_management: "密钥管理方案: 硬件安全模块/软件密钥链/远程KMS"
  data_sovereignty: "数据主权要求: 仅境内/允许跨境/需本地化存储"
  audit_requirements: "审计要求: 操作日志/变更追踪/实时审计"