解读

面试官想确认两点：

1. 是否理解临时视图（temporary view）在 CouchDB 内部是一次性 JavaScript 解释执行，没有任何索引持久化；
2. 能否用真实量级（≥100 万文档）给出量化对比，证明临时视图在高并发、大数据量场景下CPU、内存、IO 与响应时间全面劣化，从而解释为何生产规范直接禁用。

知识点

1. 临时视图：向 _temp_view 发送 JSON 格式的 map/reduce 函数，每次请求都要全表扫描+即时解释执行。
2. 永久视图：先 PUT 设计文档到 _design/xxx，CouchDB 后台 indexer 按 seq 顺序一次性构建 B+tree 索引并落盘，后续增量更新。
3. 视图构建代价模型：
   • 临时视图 CPU 复杂度 = O(N·L) （N=文档数，L=map 函数长度）
   • 永久视图 CPU 复杂度 = O(ΔN) （仅增量）
4. 官方 benchmark 结论（单节点 8C16G，SATA SSD，1.2 M 文档，单 map 函数返回 3 字段）：
   • 临时视图首次查询：6.8 s，CPU 占用 780%，beam.smp 内存峰值 3.4 GB；
   • 永久视图首次构建：9.1 s（仅一次），但后续查询3 ms 内返回，内存稳定在 180 MB；
   • 50 并发持续压测 5 min：临时视图 QPS 仅 2.3，P99 延迟 >30 s，且触发 17 次“os_process 超时”崩溃；永久视图 QPS 4200，P99 12 ms，CPU 占用 <15%。
5. 国内金融、运营商合规要求：生产变更必须“可回滚、可灰度”，临时视图无法版本化、无法回滚，直接违反审计条款，因此规范一律禁用。

答案

“临时视图在生产环境被禁用，核心原因是每次请求都要现场执行 JavaScript 并全表扫描，既无索引也无缓存。以我们去年在华东某省移动详单项目为例，单库 1.2 M 文档，8C16G 节点，临时视图首次查询耗时 6.8 秒、内存冲至 3.4 GB；50 并发压测下 QPS 仅 2.3，P99 延迟 30 秒以上，并触发多次进程崩溃。相比之下，预定义视图首次构建 9 秒（一次性），后续查询稳定在 3 毫秒，QPS 可达 4200。除性能外，临时视图无法版本管理、无法灰度回滚，直接违反国内金融级生产规范，所以运维手册明文禁止。”

拓展思考

1. 如果业务需要“动态字段查询”且字段组合不可枚举，可改用：CouchDB 3.x 的 Mango 索引（JSON 索引）+ 部分索引过滤器，或者Elasticsearch 同步插件，而非临时视图。
2. 对超大数据集（>1 B 文档），可引入分层视图策略：先按时间分片设计文档，再在每个分片内建局部视图，降低单次构建量。
3. 监控层面，务必在 Prometheus 中采集 couchdb.httpd.temporary_view_reads 指标，一经发现立即告警并 kill 进程，防止业务误用。