4. 多租户数据隔离模式：数据库级、Schema 级与表级隔离对比
在多租户可观测性平台中，数据隔离策略直接决定了租户间的安全边界、运维复杂度与查询性能。本章深入对比三种主流隔离模式：数据库级隔离（Database per Tenant）、Schema 级隔离与表级隔离（共享表 + 租户 ID 列），帮助架构师在领域建模与可观测性场景中做出合理选择。
核心权衡：隔离强度与共享效率成反比。隔离越强，资源开销与运维成本越高；共享越多，性能优化与租户间干扰控制越复杂。
4.1 三种隔离模式概述
下表从数据边界、实现方式、典型场景三个维度快速定位每种模式的核心特征：
| 隔离模式 | 数据边界 | 实现方式 | 典型场景 |
|---|---|---|---|
| 数据库级隔离 | 每个租户独占一个物理/逻辑数据库 | 连接字符串路由、数据库实例池 | 金融、医疗等强合规行业；超大规模租户 |
| Schema 级隔离 | 同一数据库内，每个租户独占一个 Schema | Schema 前缀路由、动态 SQL 切换 | 中型 SaaS 平台；租户数 100~1000 |
| 表级隔离 | 所有租户共享同一张表，通过租户 ID 列区分 | WHERE tenant_id = ? 过滤 | 轻量级多租户；可观测性日志/事件存储 |
4.2 数据库级隔离（Database per Tenant）
每个租户拥有独立的数据库实例或逻辑数据库，物理资源与连接池完全隔离。这是隔离性最强的模式，也是合规要求最高的行业首选。
优点
- 最强数据隔离：租户间无任何数据交叉风险，满足 GDPR、HIPAA 等严格合规要求。
- 独立扩缩容：可为大租户分配更多 CPU/内存/存储，不影响其他租户。
- 独立备份恢复：单个租户数据损坏时，可独立恢复，不影响全局。
- 租户级可观测性：数据库监控指标天然按租户聚合，便于计费与容量规划。
缺点
- 资源开销高：每个数据库都有独立的连接池、缓冲池、后台进程，租户数量大时总资源消耗急剧上升。
- 运维复杂度高：Schema 变更需逐个数据库执行，版本管理困难；连接管理、监控告警配置量线性增长。
- 跨租户查询困难：全局统计、平台级分析需要跨数据库聚合，通常需要额外的 ETL 或联邦查询层。
- 初始成本高：即使小租户也需要完整的数据库实例，不适合长尾租户场景。
可观测性场景建议：适用于金融级审计日志、医疗健康数据、政府合规场景。租户数量通常 < 200，每个租户数据量 > 1TB。
4.3 Schema 级隔离
所有租户共享同一个数据库实例，但每个租户拥有独立的 Schema（命名空间）。Schema 内包含完整的表结构，表名相同但数据物理隔离。
优点
- 较好的隔离性：Schema 是数据库内的逻辑边界，租户间无法直接访问对方数据。
- 资源共享：共享数据库实例的连接池、缓冲池，资源利用率高于数据库级隔离。
- 管理相对简单：Schema 变更可通过脚本批量执行，比逐个数据库操作更高效。
- 成本适中：适合 100~1000 个租户的中型 SaaS 平台。
缺点
- 实例级故障影响所有租户：数据库实例宕机或性能抖动时，所有租户同时受影响。
- 资源争抢：大租户的查询可能耗尽连接池或 IO 带宽，影响小租户。
- Schema 数量限制：部分数据库（如 MySQL）对 Schema/数据库数量有上限，或管理开销随数量增加而上升。
- 跨 Schema 查询仍较复杂：平台级分析需要遍历所有 Schema，查询性能与租户数成反比。
可观测性场景建议：适用于中型 SaaS 可观测性平台，租户数 100~500，每个租户数据量 100GB~1TB。配合连接池隔离与资源组控制可缓解资源争抢。
4.4 表级隔离（共享表 + 租户 ID 列）
所有租户共享同一张物理表，通过 tenant_id 列区分数据归属。这是资源效率最高的模式，也是可观测性场景中最常见的存储方案。
优点
- 资源效率最高：单表存储所有租户数据，数据库实例数量最少，连接池利用率最高。
- 运维最简单：只需管理少量表，Schema 变更一次生效，备份恢复策略统一。
- 跨租户分析便捷：平台级聚合查询直接在单表上执行，无需跨库/跨 Schema 操作。
- 弹性扩展：可轻松支持数千甚至数万租户，适合长尾市场。
缺点
- 隔离性最弱：数据安全完全依赖应用层过滤，一旦
WHERE tenant_id = ?遗漏或 SQL 注入，可能导致数据泄露。 - 租户间性能干扰：大租户的大量数据可能导致索引膨胀、查询变慢，影响小租户体验。
- 索引与分区设计复杂：需要精心设计分区键（通常按 tenant_id + 时间）和索引策略，否则查询性能急剧下降。
- 数据恢复粒度粗：无法单独恢复某个租户的数据，必须全表恢复或通过逻辑导出。
4.5 综合对比与选型建议
下表从 8 个关键维度对三种模式进行量化对比，帮助架构师在领域建模阶段做出决策：
| 评估维度 | 数据库级隔离 | Schema 级隔离 | 表级隔离（共享表） |
|---|---|---|---|
| 数据隔离强度 | 极高（物理隔离） | 高（逻辑隔离） | 低（应用层隔离） |
| 资源效率 | 低 | 中 | 高 |
| 运维复杂度 | 高 | 中 | 低 |
| 跨租户分析 | 困难 | 较困难 | 容易 |
| 租户扩缩容 | 灵活（独立资源） | 受限（共享实例） | 受限（共享表） |
| 备份恢复粒度 | 单租户粒度 | 单 Schema 粒度 | 全表粒度 |
| 适用租户规模 | < 200 | 100 ~ 1000 | 1000 ~ 100000+ |
| 可观测性场景匹配 | 金融审计、合规日志 | 中型 SaaS 平台 | 日志/指标/事件存储 |
架构决策提醒：不要试图用一种模式解决所有租户需求。在可观测性平台中，建议采用混合模式：核心审计数据使用数据库级隔离，常规日志/指标使用表级隔离，中型租户使用 Schema 级隔离。领域驱动设计中的限界上下文（Bounded Context）是划分隔离模式的天然边界。
4.6 领域驱动设计视角下的隔离模式选择
在 DDD 实践中，数据隔离模式应与限界上下文对齐，而非简单按租户规模一刀切：
- 核心域（Core Domain）：如计费、合规审计，采用数据库级隔离，确保最高安全性与可审计性。
- 支撑子域（Supporting Subdomain）：如告警规则、仪表盘配置，采用 Schema 级隔离，平衡隔离与共享。
- 通用子域（Generic Subdomain）：如日志存储、事件流，采用表级隔离，追求资源效率与查询性能。
这种按领域重要性分层隔离的策略，既能满足合规要求，又能控制基础设施成本，是可观测性平台多租户架构的最佳实践。