MongoDB用户画像应采用宽表设计，将静态属性放根层级、动态标签统一存入tags数组，高频字段单独提取并为tags.key/value建多键索引，更新用$addToSet/$pull避免覆盖，并对大字段另存collection+TTL兜底。
宽表结构用 document 直接嵌套，别建几十个 collection
用户画像本质是「一个人 + 一堆属性」，MongoDB 的文档天然适合存宽表。硬拆成 user、user_tags、user_behavior_summary 等多个 collection，反而增加聚合成本和事务复杂度。
常见错误是照搬关系型数据库思维，把标签当多对多关系单独建表——结果查一个用户要 $lookup 四五次，延迟翻倍，还容易因 pipeline 阶段过多触发 Exceeded memory limit for $group 错误。
- 所有静态属性（如
gender、city、register_date）直接放在根层级 - 动态标签统一收进一个字段，比如
tags：类型为数组，每个元素是带key和value的对象，例如{ "key": "interest", "value": "ai" } - 高频查询字段（如
last_login_time、is_vip）务必单独提出来，别全塞进tags里——否则每次都要遍历数组，无法走索引
tags 数组怎么建索引才不白费力气
直接对 tags 字段建普通索引没用，MongoDB 不会自动展开数组里的对象字段。想按 tags.key === "age_group" 查，必须用点号路径建多键索引。
典型坑是只建了 { "tags": 1 }，结果 find({ "tags.key": "age_group" }) 依然慢得像没索引一样——因为这个查询实际匹配的是数组中某个元素的 key 字段，不是整个 tags 数组。
- 正确方式：
db.users.createIndex({ "tags.key": 1, "tags.value": 1 }) - 如果常按单个 key 查所有 value（比如找所有
interest标签），可加{ "tags.key": 1, "tags.value": 1 }复合索引，避免排序和内存溢出 - 注意：多键索引会让文档在索引中占多条记录（数组有几个元素就几条），
tags过长（>100 项）会显著拖慢写入和索引体积，需定期清理过期标签
动态标签更新用 $addToSet + $pull，别用 $set 覆盖整数组
用户标签随时变，比如兴趣从 "sports" 切到 "tech"，或新增 "high_spender"。若每次更新都 $set: { tags: [...] }，一是网络传大量冗余数据，二是并发写可能丢标签（A 读旧数组 → B 读旧数组 → A 改完写入 → B 改完写入，后者覆盖前者）。
更糟的是用 $push 不去重，导致同一个 { key: "interest", value: "ai" } 出现 5 次，查的时候还得 $unwind 去重，白白耗内存。
- 新增唯一标签：
{$addToSet: { tags: { key: "interest", value: "ai" } }} - 删除某类标签：
{$pull: { tags: { key: "interest" } }} - 替换某 key 的 value：
{$pull: { tags: { key: "interest" } }, $addToSet: { tags: { key: "interest", value: "ml" } }}（两个操作合并进一次 update） - 别用
$each批量加一堆未去重标签——除非你确定来源已排重，否则后续查起来全是噪音
宽表字段膨胀到 16MB 限制前得有兜底策略
MongoDB 单文档硬上限是 16MB，看着大，但用户行为日志一埋、设备列表一塞、历史标签一攒，很容易触线。报错是 BSONObj size: 16793601 (0x1010001) is invalid. Size must be between 0 and 16793600(16MB)，这时候再拆已经晚了。
不是所有字段都该塞进主文档：设备指纹、点击流明细、长文本评论这些低频访问、高体积数据，早该挪出去。
- 主文档只留强查询字段：ID、基础属性、最新 N 个关键标签（如最近 3 次购买品类）、实时计算指标（
rfm_score） - 大字段另存 collection，用
user_id关联，命名如user_extended_data，并加 TTL 索引自动过期（比如设备列表保留 90 天） - 写入前加校验逻辑：统计
JSON.stringify(doc).length，接近 14MB 就触发告警或自动分流，别等报错才反应
真正难的不是设计宽表，而是判断哪些“动态”其实不该动态——比如“是否领过优惠券”这种布尔态，比存 {key:"coupon_status", value:"claimed"} 更省空间也更快查。标签不是越多越好，是够用且能被高效检索才算数。
