一、前置思考

1.1 企业级存储的复杂度远高于普通应用

普通 App 存几百 MB 数据，企业级应用动辄几十 GB：IM 消息、交易流水、操作日志、用户行为数据……数据量、访问模式、合规要求完全不是一个量级：

挑战1: 数据量大 → 单表几千万行 → 查询必须分层
挑战2: 访问不均衡 → 20% 热数据占 80% 访问 → 冷热要分离
挑战3: 增长快 → 容量规划跟不上 → 归档迫在眉睫
挑战4: 合规要求 → 数据保留期限 → 生命周期管理

1.2 企业级存储的三大支柱

读写分离: 高频读写与低频读写分开, 互不拖累
冷热分层: 热数据快速访问, 冷数据低成本存放
生命周期: 数据从创建到删除全程管理 (合规+成本)

1.3 本文路线

从 读写分离架构 → 冷热数据分层 → LSM-Tree → 归档策略 → 生命周期管理 逐层展开。

二、核心原理

2.1 读写分离架构

传统单库:
  读 + 写 都在同一数据库 → 写锁阻塞读, 读多拖累写

读写分离 (应用层模拟):
  写路径: 主库 (事务保证)
  读路径: 从库/缓存 (高吞吐)
  同步: 主→从 异步复制 (允许短暂延迟)

鸿蒙落地:
  单机 SQLite 无法物理分离 → 用"写库 + 读缓存 + 读副本"组合:
  ① 写入走 RDB (事务)
  ② 高频读走 L1/L2 缓存 (缓存库)
  ③ 低频读走 RDB

2.2 冷热数据分层

按访问频率分层:
  热数据 (L0): 最近 7 天 → 常驻内存缓存 + 主表
  温数据 (L1): 最近 90 天 → 普通表 (有索引)
  冷数据 (L2): 超过 90 天 → 归档表/归档文件 (无实时索引)

分层依据:
  访问频率 (最后访问时间)
  时间维度 (消息按天, 日志按周)
  业务价值 (订单按状态)

2.3 LSM-Tree（日志结构合并树）

为什么需要 LSM-Tree:
  传统 B-Tree 随机写慢 (每次写要更新树节点)
  LSM-Tree: 顺序写 + 内存缓冲 + 后台合并

LSM-Tree 结构:
  MemTable (内存, 写缓冲) → 满了刷盘
  SSTable (不可变有序文件) → 分层合并 (Compaction)
  读: 先查 MemTable → 逐层查 SSTable → 布隆过滤器加速

适用: 写多读少的日志/流水场景
(鸿蒙关系型存储基于 SQLite B-Tree; 理解 LSM 用于分布式KV/日志系统设计)

2.4 数据归档策略

归档 = 把冷数据从主存储搬到低成本存储

归档触发:
  按时间: 数据超过保留窗口
  按容量: 主库超过阈值
  按状态: 业务完成 (订单关闭后归档)

归档形式:
  ① 同库分区表 (按月分区, 旧分区只读)
  ② 归档表 (主表瘦身)
  ③ 归档文件 (导出 CSV/压缩包)
  ④ 冷存储 (对象存储/云端)

2.5 数据生命周期管理（DLM）

数据生命周期:
  创建 → 热存储 (高频访问) → 温存储 (降频) → 归档 → 销毁

生命周期策略 (合规驱动):
  业务数据: 保留 X 年 → 归档 → 到期销毁
  日志数据: 保留 X 天 → 到期销毁
  用户数据: 注销账号 → 立即销毁 (合规要求)

管理手段:
  生命周期规则表 (数据类 → 阶段 → 时长 → 动作)
  定时任务执行 (扫描 + 迁移 + 删除)
  审计留痕 (销毁记录)

三、源码/API 深度解析

3.1 读写分离（写库 + 读缓存）

import { relationalStore } from '@kit.ArkData';

// 主库 (写)
class WriteStore {
  private rdb: relationalStore.RdbStore | null = null;

  async init(context: Context): Promise<void> {
    this.rdb = await relationalStore.getRdbStore(context, {
      name: 'biz.db', securityLevel: relationalStore.SecurityLevel.S1
    });
  }

  async insert(table: string, data: relationalStore.ValuesBucket): Promise<number> {
    if (!this.rdb) { throw new Error('写库未初始化'); }
    return this.rdb.insert(table, data);
  }
}

// 读层: L1 内存 + L2 KV + 写库兜底
class ReadLayer {
  // 读优先缓存, 未命中再查库
  async get(table: string, key: string): Promise<string | undefined> {
    const v1 = this.memCache.get(table + ':' + key);
    if (v1 !== undefined) { return v1; }
    const v2 = await this.kvCache.get(table + ':' + key);
    if (v2 !== undefined) { this.memCache.put(table + ':' + key, v2); return v2; }
    const v3 = await this.queryDb(table, key);   // 读主库
    if (v3 !== undefined) { this.kvCache.put(table + ':' + key, v3); }
    return v3;
  }
}

3.2 冷热数据分层（时间维度）

// 消息表: 按月分区思路 → 应用层分表/分库
const MSG_HOT_TABLE = 'msg_hot';     // 最近 7 天
const MSG_ARCHIVE_TABLE = 'msg_archive';  // 归档

async function insertMessage(rdb: relationalStore.RdbStore,
  msg: relationalStore.ValuesBucket, ts: number): Promise<void> {
  const table = Date.now() - ts < 7 * 86400000 ? MSG_HOT_TABLE : MSG_ARCHIVE_TABLE;
  await rdb.insert(table, msg);
}

async function queryMessages(rdb: relationalStore.RdbStore,
  fromTs: number, toTs: number): Promise<Array<any>> {
  const results: Array<any> = [];
  // 热区间查热表, 冷区间查归档表, 跨区间并集
  if (toTs > Date.now() - 7 * 86400000) {
    results.push(...await queryTable(rdb, MSG_HOT_TABLE, fromTs, toTs));
  }
  if (fromTs < Date.now() - 7 * 86400000) {
    results.push(...await queryTable(rdb, MSG_ARCHIVE_TABLE, fromTs, toTs));
  }
  return results;
}

3.3 归档任务（定时）

// 每日归档: 把超过 7 天的热数据搬到归档表
async function dailyArchive(rdb: relationalStore.RdbStore): Promise<number> {
  const cutoff = Date.now() - 7 * 86400000;
  // 1. 读取过期热数据 (分批)
  const rs = await rdb.querySql(
    `SELECT * FROM msg_hot WHERE ts < ${cutoff} LIMIT 1000`);
  const batch: relationalStore.ValuesBucket[] = [];
  while (rs.goToNextRow()) {
    batch.push(rowToBucket(rs));
  }
  rs.close();
  // 2. 写入归档表
  if (batch.length > 0) { await rdb.batchInsert(MSG_ARCHIVE_TABLE, batch); }
  // 3. 删除热表数据
  const predicates = new relationalStore.RdbPredicates(MSG_HOT_TABLE);
  predicates.lessThan('ts', cutoff);
  await rdb.delete(predicates);
  return batch.length;
}

3.4 生命周期管理

// 生命周期规则
interface LifecycleRule {
  dataType: string;
  hotDays: number;      // 热存储时长
  archiveDays: number;  // 归档触发时长
  destroyDays: number;  // 销毁时长 (合规)
}

const RULES: LifecycleRule[] = [
  { dataType: 'message', hotDays: 7, archiveDays: 180, destroyDays: 365 },
  { dataType: 'log', hotDays: 1, archiveDays: 30, destroyDays: 90 },
  { dataType: 'order', hotDays: 90, archiveDays: 3650, destroyDays: -1 }  // -1: 永久
];

// 生命周期执行器
class LifecycleManager {
  private rules: Map<string, LifecycleRule> = new Map();
  constructor(rules: LifecycleRule[]) {
    rules.forEach(r => this.rules.set(r.dataType, r));
  }

  // 处理过期数据
  async process(dataType: string, ts: number): Promise<void> {
    const rule = this.rules.get(dataType);
    if (!rule) { return; }
    const ageDays = (Date.now() - ts) / 86400000;

    if (rule.destroyDays > 0 && ageDays > rule.destroyDays) {
      await this.destroy(dataType, ts);         // 销毁 (合规)
    } else if (ageDays > rule.archiveDays) {
      await this.archive(dataType, ts);         // 归档
    } else if (ageDays > rule.hotDays) {
      await this.coolDown(dataType, ts);        // 热→温
    }
  }
}

四、企业级实战落地

4.1 企业级存储架构全景

┌────────────────────────────────────────────────┐
│ 访问层: 读请求 → L1内存 → L2KV → 读主库(兜底)    │
│         写请求 → 写主库(事务) → 缓存失效         │
├────────────────────────────────────────────────┤
│ 数据层:                                        │
│  热数据: 主表 (7天) → 常驻缓存                  │
│  温数据: 主表/温表 (90天) → 索引查询             │
│  冷数据: 归档表/文件 (>90天) → 低频率访问        │
├────────────────────────────────────────────────┤
│ 生命周期层:                                    │
│  定时任务: 冷热迁移 → 归档 → 销毁               │
│  合规规则: 保留期限 → 到期删除                   │
├────────────────────────────────────────────────┤
│ 容量层: 空间监控 → 预警 → 归档扩容               │
└────────────────────────────────────────────────┘

4.2 IM 消息存储落地

热: 最近 7 天消息 → 主表 + 内存缓存 (秒开)
温: 7-90 天 → 主表分页查询 (索引)
冷: >90 天 → 归档表 (季度归档)
销毁: 合规要求 1 年 → 到期删除
容量: 单用户消息上限 + 全局容量监控

4.3 日志存储落地

热: 当天日志 → 内存缓冲 → 批量写
温: 30 天内 → 日志表 (按天分表)
冷: 30-90 天 → 压缩归档文件
销毁: >90 天 → 删除 (合规保留期)

4.4 性能与成本对照（模拟）

方案	1000万条查询	存储成本	维护复杂度
单表全量	2.8s (退化)	高	低
分区表	0.3s	中	中
冷热分层	热0.05s/冷0.5s	低	中
读写分离+分层	热0.01s	低	高

五、问题排查与性能优化

坑	现象	原因	解决
单表膨胀查询退化	越来越慢	无分层	冷热分层
缓存与库不一致	读到旧数据	写后未失效	写库后删缓存
归档失败	热表只增不减	定时任务失效	任务监控 + 重试
冷数据误删	合规风险	规则错误	生命周期规则审查
归档查询慢	冷数据难查	无索引	归档表轻索引
容量爆炸	日志无限增长	无销毁	生命周期销毁
写放大	日志写频繁	逐条写	批量写入

5.1 归档准确性保障

归档三步校验:
  ① 归档前 count 对比 (热表待搬 vs 归档表已搬)
  ② 归档后抽样验证 (随机 N 条对比)
  ③ 删除前二次确认 (归档完整才删热数据)

5.2 容量规划

容量模型: 日增 × 保留期 × 膨胀系数 = 需求容量
监控: 每表大小 / 增长率 / 预测触顶时间
预警: 触顶前 30 天 → 归档扩容 / 缩短保留期

5.3 合规红线

生命周期规则必须可审计:
  每类数据的保留期限 → 配置化 + 变更留痕
  销毁动作 → 记录 + 双重确认
  用户数据 → 注销即删 (硬性合规)
  数据可导出 → 合规导出接口

六、高阶总结与最佳实践

1. 读写分离：写库保事务、读层走缓存，高频读不打垮写路径。
2. 冷热分层：20% 热数据享受全速访问，80% 冷数据低成本存放。
3. LSM-Tree 思维：写多读少场景顺序写 + 后台合并（分布式 KV/日志系统）。
4. 归档必做：数据只涨不缩会拖垮主库，定时归档 + 三步校验。
5. 生命周期即合规：保留期限配置化、销毁留痕、用户数据注销即删。

一句话记住：读写分离防拖累、冷热分层降成本、归档迁移控容量、生命周期保合规——企业级存储的本质是"让数据各得其所，全程可管可控"。