Chrome向量数据库实战：如何解决浏览器端大规模相似性搜索的性能瓶颈

共计 2685 个字符，预计需要花费 7 分钟才能阅读完成。

开篇：浏览器端向量搜索的痛点

在构建需要相似性搜索功能的 PWA 应用时，传统纯 JavaScript 方案在数据量达到万级后就会暴露出明显问题：

• 内存占用飙升：加载 10,000 条 768 维向量需要约 234MB 内存（Float32Array 存储）
• 计算速度缓慢：在 i5-8250U 笔记本上，全量线性搜索 1000 条向量需要 1200ms+
• 主线程阻塞：计算过程中 UI 完全冻结，用户体验指数级下降

技术路线对比

我们评估了三种主流技术路线在 Chrome 104 上的表现：

1. 纯 WebAssembly 方案
2. 优点：可调用 SIMD 指令，计算性能最佳

3. 缺点：需要预分配连续内存，数据量大时容易 OOM

4. Service Worker + IndexedDB

5. 优点：后台运行不阻塞 UI，存储容量大（通常≥50MB）

6. 缺点：线程通信开销大，实时性较差

7. TensorFlow.js 方案

8. 优点：内置 GPU 加速，API 友好
9. 缺点：模型加载耗时长，包体积增加 300KB+

最终采用混合方案：Web Workers 处理计算 + IndexedDB 持久化 + WASM SIMD 加速关键路径

核心实现解析

IndexedDB 存储优化

// 初始化向量数据库
const openDB = () => new Promise((resolve) => {const request = indexedDB.open('VectorDB', 2);

  request.onupgradeneeded = (e) => {
    const db = e.target.result;
    if (!db.objectStoreNames.contains('vectors')) {const store = db.createObjectStore('vectors', { keyPath: 'id'});
      store.createIndex('embedding', 'embedding', { unique: false});
    }
  };

  request.onsuccess = (e) => resolve(e.target.result);
});

关键设计点：

• 将长向量分段存储（每 5 个维度一组）避免超过 Chrome 的 Value 大小限制
• 采用增量写入策略，单次事务不超过 100 条写入

Web Workers 并行计算

主线程与 Worker 的通信优化：

// 主线程
const worker = new Worker('search.worker.js');
const search = (query) => {const transfer = [query.buffer]; // 使用 Transferable 对象
  worker.postMessage({type: 'SEARCH', query}, transfer);
};

// Worker 端
onmessage = ({data}) => {if (data.type === 'SEARCH') {const results = performSearch(data.query);
    postMessage(results, [results.buffer]); // 返回结果同样 Transfer
  }
};

SIMD 加速的余弦相似度

// search_simd.cpp
float cosineSimilarity(const float* a, const float* b, int size) {__m128 sum = _mm_setzero_ps();
  __m128 normA = _mm_setzero_ps();
  __m128 normB = _mm_setzero_ps();

  for (int i = 0; i < size; i += 4) {__m128 vecA = _mm_load_ps(a + i);
    __m128 vecB = _mm_load_ps(b + i);

    sum = _mm_add_ps(sum, _mm_mul_ps(vecA, vecB));
    normA = _mm_add_ps(normA, _mm_mul_ps(vecA, vecA));
    normB = _mm_add_ps(normB, _mm_mul_ps(vecB, vecB));
  }

  float result[4];
  _mm_store_ps(result, sum);
  float dot = result[0] + result[1] + result[2] + result[3];

  _mm_store_ps(result, normA);
  float aNorm = sqrt(result[0] + result[1] + result[2] + result[3]);

  _mm_store_ps(result, normB);
  float bNorm = sqrt(result[0] + result[1] + result[2] + result[3]);

  return dot / (aNorm * bNorm);
}

性能测试数据

测试环境：
– 设备：MacBook Pro (M1, 2020)
– Chrome 版本：104.0.5112.101
– 数据集：768 维向量，Float32 存储

避坑指南

IndexedDB 事务超时

• 症状：大量写入时出现 ”TransactionInactiveError”

• 解决方案：

• 将批量写入拆分为多个子事务

• 每个事务完成后手动触发 GC：

  await new Promise(r => setTimeout(r, 0));

Web Workers 通信优化

• 避免频繁小消息：合并多个搜索请求为批次处理
• 使用 Transferable 对象减少拷贝：

  // 传递 ArrayBuffer 而非 Array
  worker.postMessage({buffer: arrayBuffer}, [arrayBuffer]);

内存泄漏排查

1. 在 Chrome DevTools 的 Memory 面板定期进行堆快照
2. 特别注意 WASM 内存的主动释放：

   extern "C" {void free_buffer(void* ptr) {free(ptr);
     }
   }

开放性问题：增量索引更新

当前方案在新增数据时需要重建整个索引，后续可探索：

1. 基于 LSM-Tree 的分层索引结构
2. 利用 Service Worker 实现后台增量构建
3. 参考 Faiss 的 IVF 索引实现浏览器端近似搜索

总结

通过组合 IndexedDB 的存储能力、Web Workers 的并行计算和 WASM 的 SIMD 加速，我们成功在浏览器端实现了万级向量的毫秒级搜索。这种方案特别适合需要离线运行的 PWA 应用，如：

• 本地图片搜索引擎
• 客户端的推荐系统
• 浏览器插件的语义分析

下一步将重点优化索引更新机制，让方案能更好地适应生产环境的数据变化频率。