解读

在国内 CouchDB 岗位面试中，面试官常通过“group_level 对聚合结果的影响”来验证候选人是否真正理解 Map 端输出 key 的数组结构与 Reduce 端分组粒度的对应关系。该问题表面问参数，实则考察对“复合键 + 视图聚合”底层逻辑的掌握，答不出“key 长度与 group_level 数值的匹配规则”会被直接判定为“仅会调 API，未读过源码”。

知识点

1. 复合键（compound key）：map 函数 emit([year, month, day], value) 时，key 是 JSON 数组。
2. group_level 语义：
   • 0：对整个视图做全局聚合，返回一行，key=null。
   • 1…N：只取数组前 N 个元素做前缀分组，前缀相同即同组；返回多行，每行 key 为被截断后的前缀数组。
3. _sum / _count 属于内置 Reduce，二者都遵守同一套分组规则；区别仅在于聚合值是求和还是计数。
4. 返回结构字段：rows[] 中每行包含 {key, value}，key 形态随 group_level 动态变化，value 为聚合结果。
5. 国内生产注意：离线同步场景下，group_level 若设置过大，易造成中间状态膨胀，需配合 _count 做阈值监控，防止移动端同步超时。

答案

以 emit([2023,5,1], 1) 、emit([2023,5,2], 1) 、emit([2023,6,1], 1) 三行数据为例：

• group_level=0：返回一行
  {"key":null,"value":3}
• group_level=1：按第一维分组，返回两行
  {"key":[2023],"value":3}
• group_level=2：按前两维分组，返回三行
  {"key":[2023,5],"value":2}
  {"key":[2023,6],"value":1}
• group_level=exact（或≥3）：完全匹配，返回三行
  {"key":[2023,5,1],"value":1}
  {"key":[2023,5,2],"value":1}
  {"key":[2023,6,1],"value":1}

结论：group_level 决定“取数组前几位做前缀”，从而直接控制返回行数与 key 的形态；_sum 与 _count 仅影响 value 字段，不影响 key 的截断规则。

拓展思考

1. 如果 map 阶段 emit 的不是数组而是字符串，group_level 会退化为 0 或 exact 两档，前缀分组失效；国内有些候选人误把字符串当数组用，导致聚合结果始终只有一行，面试现场可据此追问“如何快速定位此类错误”。
2. 在多主复制场景下，不同节点可能因写入顺序差异产生相同复合键，group_level 聚合后会出现“同一前缀不同值”的冲突视图；解决思路是加业务维度到 key 尾部，再用 group_level 跳过该维度，保证幂等聚合。
3. 对于移动端离线包，group_level 过大会使 B-tree 中间节点增多，同步流量上升；国内落地时常用“_count + group_level=1”做日报汇总，把结果写入本地 SQLite，减少后续 CouchDB 查询次数，实现“离线优先，在线补偿”的混合策略。