如何为Microsoft 365备份审计数据建模Azure Cosmos DB(SQL API)

核心建议：拆分存储，不嵌入backup_items #

1万条backup_items极大概率会突破Cosmos DB单文档2MB的上限（按单条item平均100字节计算，1万条就接近1MB，若字段增加很容易超标），而且拆分存储更适配审计场景的查询需求。

具体建模结构 #

1. 备份作业文档（存储固定元数据）

分区键建议设为backup_job_id，确保同作业的所有文档在同一分区，关联查询更高效：

{
   "id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx", // 可直接复用backup_job_id保证唯一性
   "backup_job_id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx",
   "backup_job_name": "Exchange Backup Job",
   "schedulePolicy": {
        "type": "Daily",
        "dailyType": "Everyday",
        "dailyTime": "08:37:00"
    },
    "doc_type": "backup_job" // 标记文档类型，方便跨类型筛选查询
}

2. 备份会话文档（存储会话级结果）

仅保留会话核心信息，不包含backup_items，分区键同样用backup_job_id：

{
   "id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx", // 直接用backup_job_session_id作为id
   "backup_job_id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx",
   "backup_job_session_id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx",
   "backup_job_session_status": "Success",
   "session_start_time": "2024-05-20T08:37:00Z", // 新增会话时间，便于审计排序和筛选
   "doc_type": "backup_session"
}

3. 备份项文档（单条备份结果独立存储）

每条backup_item作为单独文档，分区键仍为backup_job_id：

{
   "id": "session-xxxxxx-user-1", // 用会话ID+用户ID组合确保全局唯一
   "backup_job_id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx",
   "backup_job_session_id": "xxxxxx-xxxxxx-xxxxxx-xxxxxxx",
   "user_id": "1",
   "user_name": "User 1",
   "user_email": "user1@organization.onmicrosoft.com",
   "backup_status": "Success",
   "doc_type": "backup_item"
}

拆分建模的优势 #

• 避免大小超限：彻底规避单文档2MB限制，写入操作更稳定，不会出现因文档过大导致的写入失败。
• 优化查询效率：审计场景常见的查询（比如某会话的所有失败备份项、某用户的历史备份记录），可以直接通过backup_job_id+backup_job_session_id+backup_status或user_email过滤，无需嵌套查询大文档，节省RU和带宽。
• 扩展性更强：后续新增备份项字段或增加备份数量时，不会受限于单文档大小，无需调整数据结构。

特殊情况：可选嵌入方案 #

如果经过精确测算，单会话所有backup_items的总字节数肯定在2MB以内（比如每个item仅包含3-4个短字段，总大小控制在1.5MB以下），也可以选择嵌入到备份会话文档中，但需注意：

• 读取会话时会加载所有备份项，若仅需部分数据（如仅查失败项），会造成不必要的资源浪费。
• 后续若备份项字段扩展，很容易触发大小限制，灵活性差。

内容的提问来源于stack exchange，提问作者Lama Youz