Why I Built a Vector Database Around Disk Instead of RAM
说明与用途
AsterVec 是一种将 HNSW 索引拆分为向量和图边两部分的磁盘向量数据库,限制 RAM 使用并保持高查询和插入吞吐量。
问题
Embedded vector stores grow in RAM, competing with LLMs and other AI components on a single machine.
结果
AsterVec delivers 5.2× the queries per second and 7.3× the inserts per second of Chroma at 100K vectors, using half the memory, and maintains comparable recall. At 1M vectors it serves from disk with ~0.3 GB RAM versus Chroma’s 1.2 GB, keeping query speed and recall similar while freeing memory for other AI components.
工作流
- 1. Identify memory bottleneck in embedded vector store.
- 2. Split HNSW index into two on‑disk stores: graph edges in an LSM‑tree, vectors in a page‑based array with locality cache.
- 3. Keep only navigation layers and caches in RAM, bounding resident footprint.
- 4. Benchmark against Chroma and LanceDB on SIFT dataset at 100K and 1M vectors.
- 5. Deploy AsterVec via pip and integrate into local RAG pipeline.
证据
AsterVec serves 5.2x Chroma's queries per second and 7.3x its inserts per second, in half the memory, with recall on par.
At a million vectors, AsterVec is genuinely serving from disk: Queries run in roughly 0.3 GB of engine memory against Chroma's 1.2 GB, query speed stays in the same ballpark, and recall is slightly ahead.
- 记录日期: 2026-09-08T14:00:15.141Z