Browser Native Data Engine

业务背景：日志的自由接入，把复杂度推到了浏览器

日志系统的价值在于帮助用户处理分布式系统中的海量日志：通过 Agent 采集、全文检索和场景化查询，让开发、运维和业务人员能够定位故障、分析链路和追溯行为。采集侧为了保留用户的自主接入能力，不要求所有日志统一格式，也不把单条日志和总量限制在一个理想范围内。

这意味着前端收到的数据可能是非结构化文本、嵌套 JSON、超长字段、带高亮标记的查询结果，甚至包含大整数。真实案例中，单条日志超过 1 MB、5 MB、10 MB，甚至达到 17 MB；一次查询 24～50 条数据，响应体达到 180～400 MB 并不罕见。

案例：40 条数据的 content-length 约 398 MB。问题从“渲染几行表格”变成“浏览器如何管理一段大型数据集”。

用户真正需要的并不是在第一帧看到所有字节，而是对结果集进行一组局部操作：查看某一行、搜索关键词、定位命中、展开 JSON、复制原文、查看高亮、按字段筛选。这组需求要求数据可寻址、可延迟解析、可重复读取，而不是要求所有 payload 同时进入 UI。

两个真实请求：从请求体到浏览器崩溃

这里不是五个独立场景，而是两次真实请求的两个观察面。40 条请求同时提供了 content-length 和 HTTP 面板数据；4 MB、5 MB 是这批结果中具有代表性的单行日志；24 条请求则展示了“行数减少，但响应仍然巨大”的另一种风险。

Request A

40 条数据：约 400 MB 的一次检索

这是同一请求的两个记录：content-length 从字节角度给出响应长度，HTTP 面板从 KB 角度展示网络统计。两个数字不是两个场景，而是同一次请求在不同观测面上的表现。

40 rows

417,583,636content-length / bytes

≈398.1 MiB二进制体积估算

417,814 KBHTTP 面板记录

≈10.0 MB平均每行（粗略）

如何理解：Network 下载完成并不代表页面安全。此后还要经历字符串解码、JSON 解析、字段映射、highlight overlay、渲染对象和表格更新。若这些步骤在主线程全量执行，约 400 MB 的响应会被放大成更高的瞬时内存峰值。

Request 40 rows→417,583,636 bytes→JSON / row view→Long Task / OOM

Request B

24 条数据：约 183 MB 的“较小”请求

24 条看起来比 40 条轻，但 HTTP 面板仍显示 187,344 KB。这个请求说明：风险不由行数单独决定，少量超长日志依然可以让单次检索进入浏览器高压区。

数据规模说明：这里的 187,344 KB 只用于展示这次 24 条数据请求的返回体大小。24 条并不意味着数据量小：平均每行约 7.6 MB，且实际分布可能包含 4～5 MB 甚至更大的长尾日志。响应返回之后，还需要经历 Blob/文本读取、BigNumber 解析、复杂 Object 构造、JSON string 格式化、分词、高亮、时间处理、别名映射和 Vue 2 响应式处理；这些后处理会继续增加内存占用，最终风险取决于数据处理链，而不只是 Network 面板上的返回体大小。

24 rows

187,344 KBHTTP 面板记录

≈182.95 MiB二进制体积估算

24返回行数

≈7.6 MB平均每行（粗略）

如何理解：24 条数据的关键问题不是行数，而是返回体仍达到约 183 MB。数据进入浏览器后，即使只展示其中几行，后续的解析、对象展开、字段派生、分词、高亮、JSON 格式化和响应式处理仍可能制造大量中间对象；因此需要重点观察 Response 之后的处理链和内存峰值。

Request 24 rows→187,344 KB→全量解析与对象派生→内存峰值上升

单行视图：两个请求中的长尾数据

4 MB 和 5 MB 单行日志不是额外的第三、第四个请求，而是上述请求返回结果中的代表性 row。它们解释了为什么“平均每行大小”会掩盖真实问题：一次请求可能由少量超长行贡献主要的解析和渲染峰值。

两个请求的共同故障链

无论是 40 条还是 24 条，问题都不是某个单独数字，而是数据从网络进入浏览器之后连续穿过了多个放大点：

日志场景复杂度：Response 之后才是真正的处理链

请求返回的 ROW LIST 不是一组简单的字符串数组。每个 row 通常是一个 Object，字段类型混合存在：Value 可能是 JSON string、Text、Object、Number 或 Boolean；Object 的 KEY 可能超过 1000 个，嵌套深度实际可能达到 10 层以上。于是，Response 到达以后，浏览器面对的不是一次展示，而是一组连续的数据加工任务。

交互实验：改变“平均单行大小”，观察风险阶段

当前规模下，整包 JSON 和 UI 副本仍有明显峰值；应优先采用流式摄取与按行持久化。

旧版本的关键代价：为了避免普通 JSON.parse 对大整数造成精度丢失，响应从 JSON 处理改为 Blob，再读取文本并优先执行 BigNumber Parse。它解决了数据正确性，却把整包 Blob、文本字符串、BigNumber 解析对象和渲染对象同时推入内存，形成更高的峰值和更长的 CPU 占用。因此，Blob 不是内存优化方案；它只是改变了响应读取方式。真正的优化需要把 BigNumber 解析拆到 Worker，并进一步采用 NDJSON 的逐行解析与批量落库。

为什么 JSON.parse 会让浏览器“卡住”，甚至崩溃

“JSON.parse 很快”只在小对象上成立。对本场景，JSON.parse 只是把约 200 MB 的网络响应转换成 Object Tree，并不是最终内存。后续还会发生别名映射、JSON string 二次解析、文本分词、高亮、时间格式化、Vue 2 响应式转换以及 Watch / Computed 依赖收集。真正需要回答的问题是：同一份数据在这些阶段是否仍然被引用，以及每个阶段增加了多少对象、字符串和索引。

const text = await response.text();  // 整包落地
const rows = JSON.parse(text);        // 同步阻塞
const view = rows.map(formatRow);     // 再复制/格式化
render(view);                         // 触发布局与绘制

2.1 分阶段估算：200 MB Response 如何走向 2.2～3.6 GB

场景假设：ROW LIST 是 Array<Object>；单行可能有 1000+ Key、10+ 层嵌套；Value 混合 JSON string、Text、Object、Number、Boolean；后处理包含 Alias、Tokenizer、Highlight、JSON Format、Timestamp Format，并且全量进入 Vue 2 响应式系统。

2.2 线性 Response，不代表线性内存

这些区间用于解释内存膨胀趋势，不应替代实际监控数据。相同 Response 在字段数、对象层级、JSON string 比例、token 数量和 Vue 响应式范围不同的情况下，可能落在不同区间。

2.3 内存放大：响应体不是最终内存

如果响应体是 200 MB，浏览器至少可能同时保留 UTF-16 字符串、解析后的对象、用于展示的投影对象，以及组件/编辑器内部的数据结构。真实占用取决于引擎、字段类型和复制路径，不能简单用“响应体大小”估算；但可以确定的是，一次性全量模型会放大峰值。

2.4 长任务：主线程是单线程调度器

浏览器主线程需要同时处理 JavaScript、样式计算、Layout、Paint、输入和框架更新。当 JSON.parse、深层遍历或大规模格式化形成一个长任务时，事件循环无法及时处理用户输入，表现为滚动掉帧、点击无响应、标签页假死。若内存分配持续失败，最终可能是页面崩溃，而非一个可捕获的业务异常。

2.5 DOM 与编辑器：VirtualList 不能替代数据架构

VirtualList 解决的是“当前 DOM 节点数量”，不能解决全量数据已经被解析、复制和保存在内存中的问题。Monaco、CodeMirror 等编辑器还会建立 token、行索引和装饰模型；把 17 MB 文本交给它们，成本会再次增加。

从问题阶段到 Browser Native Data Engine

这不是“先做一个页面，最后加一个缓存”的线性升级，而是一轮由数据规模驱动的探索：先确认问题来自哪里，再组合能够延长系统可用区间的方案，最后重新定义浏览器中数据的所有权、解析边界和生命周期。

探索一：如何控制解析膨胀

第一步不是“把 JSON.parse 换成另一个 API”，而是拆开整包解析的连续成本。响应按字节读取，判断真实 Content-Type；流式响应按 meta / row / done 处理，普通 JSON envelope 保留 fallback（ndjson-stream.ts / Worker ingest）。每个 row 在 Worker 内生成 origin、renderOverlay 与 renderMeta，再由 StreamWriter 批量落库，避免主线程同时持有整包字符串、对象树和 UI 副本。

探索二：如何让数据离开内存而不是离开能力

如果把所有能力都建立在 Vuex 的完整 rows 上，搜索、复制和展开都必须持有大对象。新的所有权模型是：Vuex 持有查询状态、row_keys、total 和 loading；retrieve-row.repository 持有可恢复 Row Entity；retrieve-row-cache 保留约 24MB 热数据；renderMeta/overlay 保存截断与高亮派生信息。数据可从内存淘汰，能力仍通过 key 重新读取。

探索三：如何解决 Vue 依赖放大

Vue 2 的响应式系统适合业务状态，不适合承载数百 MB 的深层数据集。将大 payload 从响应式对象中隔离出来，只把轻量的 query state、row_keys 和交互状态交给 Vue；可见行通过异步读取得到非响应式投影，避免对完整 ROW LIST 建立 watch/computed 依赖图。

探索四：如何避免主进程阻塞

当解析、BigNumber、字段遍历和批量写入全部发生在主线程时，事件循环没有机会处理输入和绘制。retrieve-search-worker.service 串行调度，Worker 负责 fetch、解析、取消和 IndexedDB 写入；主线程只接收 meta、首行 progress、完整 row_keys、timings 和错误。Worker 是解析边界与 UI 边界的隔离层，不是附加优化。

最终分层架构：把探索结果固化为职责

从 Data Engine 到 Browser Native Data Platform

这里的 Native 不是指浏览器内置了某个数据库产品，而是指利用浏览器原生能力构造一套数据处理运行时：ReadableStream、Web Worker、IndexedDB、AbortController、事件循环和虚拟化渲染共同成为数据引擎的基础设施。

但这些基础设施只有在“读取之后立即预处理、预处理结果可复用、原始数据与展示数据分离”的前提下，才能真正降低内存压力。ReadableStream 获取到数据后，不直接把完整 ROW LIST 交给 View，而是在 Worker 内完成面向展示和交互的轻量预处理。

它与普通前端页面的区别是：系统管理的不是一次 HTTP Response，而是一个可持续访问的 DataSet。页面拥有查询状态和用户意图；Platform 负责 DataSet、Entity Identity、Component、Projection、生命周期和存储 Provider。UI 通过 EntityId 和 Projection 获取结果，永远不直接依赖底层 Storage。

数据层设计：从"响应对象"到"可寻址实体"

传统数据层将 Response 视为"一个大对象"——业务流程围绕 Object Tree 展开，组件通过 response.data.list 直接消费。当 Response 放大到数百 MB 时，这种依赖关系成为灾难：任何一个组件只要有 row 引用，整批数据就无法被 GC 回收。

可寻址实体模型的核心转变是：数据的身份不再由"它在对象树中的路径"决定，而是由 queryKey / rowKey 决定。Vuex 只保存查询状态、结果元数据和 row_keys；完整行由 Worker 解析后写入 IndexedDB，页面通过 key 按需读取渲染投影。

5.1 所有权边界：谁持有什么

与当前 retrieve-v3 实现一致：主线程不持有完整行数组；Worker 不渲染 UI；View 不直连 IndexedDB。边界按下图划分。

5.2 写入路径 vs 读取路径

旧图把摄取与渲染揉在同一条“15 步点阵”里，消息方向不清晰。正确拆法是两条反向路径：写入让大对象离开主线程，读取只按可见窗口取投影。

5.3 跨参与者消息序列（标准读写）

下表按“发送方 → 接收方”列出关键消息，对应 retrieve-search-actions → Worker Service → Worker → IndexedDB → Vuex → 结果组件。

后端响应
  ├─ meta / 结果元数据 ──► Worker progress ──► Vuex indexSetQueryResult
  └─ row / origin_data + data
       └─► RetrieveRowRepository
            └─► IndexedDB retrieveRows
                 └─► row_keys ──► Vuex
                      └─► SearchResultPanel / LogRows
                           └─► retrieveRowCacheService 按 key 读取
                                └─► 渲染行 = origin + overlay + renderMeta

5.4 行实体结构：一份记录，三类载荷

实现上不是三套独立主键，而是 retrieveRows 中一条 RetrieveRowEntity（key = queryKey:seq）同时携带原始行与渲染派生信息；字段元数据则按 field_scope 单独持久化。

5.5 IndexedDB Schema（bklog-web-storage）

以当前 Dexie schema 为准。行数据与字段元数据分表；活跃查询心跳保护 GC 不误删正在使用的结果集。

5.6 写入策略：批量阈值 + replace/append + 竞态

5.7 数据流标识：各阶段可寻址身份

UI 不持有数据对象，只持有标识；通过标识访问 Repository / Cache。

5.8 参与者职责隔离

主线程不持有完整 Response 行数组；Worker 不负责 UI 渲染；Repository 不暴露 原始 IDB 连接给业务组件；View 不直接读取 IndexedDB。协作协议是 key + projection + progress 控制消息。

一次检索请求的完整生命周期

完整生命周期包含两段：页面初始化（索引集与字段）与主查询流式摄取。前者走主线程 http.request；后者走 Worker fetch 旁路。二者都依赖 Vuex 中的空间/索引状态，但只有后者把大结果集实体化到 IndexedDB。

首屏与分页为什么使用不同写入模式

首屏使用 replace：新 row_query_key 建立后删除该查询旧行，并释放上一查询缓存。分页使用 append：沿用当前 queryKey，以已有 row_keys.length 作为 startSeq。若首屏流尚未结束，分页会被标记为 initial-search-loading 并忽略，避免 append 抢占 replace。

进度事件为什么只发送 meta 和首行

Worker 在 meta 到达时更新 total 等结果元数据；首行写入后发一次 progress，用于尽早计算默认列宽；完整 row_keys 在 done 后回传。主线程收到的是小型控制消息，而不是逐行大对象，避免流式过程中反复重排表格。

旧响应如何被丢弃

每次查询携带独立 queryKey、requestId、pageInstanceId。回调应用前检查是否仍为当前请求；不匹配则标记 stale，只清理自身查询键写入的缓存，不覆盖当前 Vuex 结果。分页取消属于控制流：保留已有行键和总数，不把正常竞态展示为错误。

卸载与回收

页面卸载时取消进行中的请求，释放当前查询的活跃标记与行缓存，并重置结果元数据、字段运行态。GC 结合 TTL（行默认约 30 分钟）与 activeRetrieveQueries 心跳，排除仍在使用的 queryKey。

项目内关键实现的对应关系

以下对应日志检索 V3 主链路中的职责划分。结果面板部分仍复用既有展示组件，但数据访问已改为按行键读取存储层，而不是持有完整结果数组。

主查询旁路 vs 常规接口调用

NDJSON 与普通 JSON 的兼容

const contentType = response.headers.get('content-type') || '';
if (shouldUseNDJSONStream(url, contentType)) {
  result = await ingestNDJSONStream(message, response, timings);
} else {
  // 后端未流式或中间层缓冲时，完整 envelope 仍可正常处理
  result = await ingestJsonEnvelopeRows(message, await parseJsonEnvelope(response), timings);
}

为什么使用大数安全解析

日志中的时间戳、ID 或业务序号可能超过 JavaScript 安全整数范围。后台摄取侧使用大数安全解析，避免普通 JSON.parse 把大整数静默舍入。这是数据正确性要求；性能优化来自“放到后台任务 + 流式/批量”，而不是去掉精度保护。

故障与降级边界

• 后台任务不可用：直接报告能力不可用，不假装能完成大数据摄取。
• 持久化存储不可用：提示兼容性问题并降级到有限易失内存；刷新后不保留。
• 请求超时或任务错误：取消任务、清理等待队列，必要时重建任务运行时。
• 存储写入失败：重置健康状态，保留当前页可用性，但不继续把无限数据塞进主线程。
• 响应被取消：作为控制流处理，保留已成功缓存的结果，不把正常取消显示为无数据。
• 字段与查询分支不一致：会导致投影/列错误；编排层必须按检索类型选择同一分支接口。

方案收益、边界与工程权衡

如何验证这套架构真的有效

1. 记录 fetch、stream、write、total 各阶段耗时（Worker timings），而不是只看接口耗时。
2. 记录解析峰值、热缓存字节数、IndexedDB 写入批次、行数和 GC 清理量。
3. 在 4 MB、5 MB、17 MB 单行和 24/40/50 行组合下测试首屏、滚动、搜索、展开、复制和取消。
4. 用 Performance Long Task、内存快照和页面崩溃率验证主线程是否从大 payload 解耦。
5. 覆盖慢网络、后端返回普通 JSON、Worker 失败、IndexedDB 禁用、连续快速查询、首屏未完成时分页、联合/场景分支。
6. 卸载页面后确认活跃查询标记释放、请求取消，且无错误把取消展示为“无数据”。

从超大日志承载走向可复用的浏览器数据基础设施

当前 retrieve-v3 已把“检索结果”从一次性响应提升为浏览器内可寻址数据集：流式摄取、Worker 解析、IndexedDB 实体、row_keys 查询、可见窗口渲染、竞态与降级边界。后续演进应围绕引擎能力，而不是单个页面组件。

Browser Data Engine 的本质，不是“把 IndexedDB 接进页面”，而是重新设计数据在浏览器中的生命周期：数据流式到达、在 Worker 中解析、以实体形式持久化、以 key 形式查询、以窗口形式渲染、以事件形式交互，并在每个环节设置容量和故障边界。

展望：从本地数据引擎到 Browser Native AI

当结果集以 Entity 形式进入 IndexedDB，浏览器就具备可持续访问的本地数据面。后续可以在不重复拉取完整 Response 的前提下，围绕当前 queryKey 做复盘、局部查询和智能交互——前提是答案必须绑定 rowKey、字段与时间范围。

实际证据：常规业务与极端连续大请求

证据分两档：95% 常规业务下，瞬时内存约 500+ MB、稳定后约 350 MB 左右；极端连续大请求下，四次合计传输约 1.05 GB，主线程仍可稳定在约 1,236 MB，而不是随累计下载线性堆到数 GB。

10.1 95% 业务：瞬时约 500+ MB，稳定约 350 MB 左右

常规检索以较小的流式响应为主（单次约百 KB～两百 KB 量级）。摄取与渲染过程中主线程会出现瞬时抬升，回落后稳定在约 350 MB 左右。

10.2 极端场景：四次大请求合计约 1.05 GB，内存约 1,236 MB

连续发起多次超大结果检索时，网络累计超过 1 GB；主线程 JS 堆稳定在约 1,236 MB，并未按累计下载量线性放大。