Optimize CAGRA HNSW FBIN bulk indexing - #2594
Draft
nvzm123 wants to merge 3 commits into
Draft
Conversation
- validate bulk-build ownership, counts, and external FBIN descriptors - make mapped ingestion, cancellation, and native cleanup failure-safe - report build metrics accurately and strengthen GPU regression coverage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This extends the controlled
CagraHnswBulkIndexWriterAPI added in #2481 (and since reverted in #2597) with opt-in mapped and immutable external-FBIN ingestion for CAGRA-to-HNSW index builds. External-file ownership and one-shot lifecycle controls remain outside the generic Lucene codec API.Related to cuvs-issue #2592.
Motivation
Bulk indexing often begins with a complete FBIN on local disk. Normal Lucene ingestion decodes and copies every vector into an intermediate native matrix, then persists another complete vector copy in the Lucene index. This is particularly expensive for high-dimensional datasets.
The bulk writer owns the
IndexWriterconfiguration and lifecycle, allowing it to enforce the conditions borrowed storage requires: an exact dense-vector count and order, one controlled flush per segment, no index sort, and no vector merges.Changes
.vecpayload.addIndexesandHardlinkCopyDirectoryWrapperwithout merging their graphs.degree, and actual adjacency bytes with truthful CPU/GPU/PCIe/disk labels and min/max gauges when
segments differ.
Benchmarks
All measurements used cold FBIN sources, with zero source bytes resident before
the benchmark JVM.
External storage
WikiANN 10M, 768d:
External storage reduced build time by 24.08% and avoided 30.72 GB of writes.
Multi-segment builds
External PREFETCH, graph degree 32, intermediate degree 48, efSearch 1500:
Validation
mvn -o spotless:check install: 424 tests, 0 failures/errors, 30 skippedgit diff --check: passedCoverage includes uneven slices, exact vector and global-ID preservation,
self-contained source deletion, external registration lifetime and relocation,
single-scan multi-segment validation, failure rollback, interruption,
cancellation, and concurrent metric aggregation.
Constraints
Lucene101AcceleratedHNSWCodecindexes: GPU CAGRA construction followed by CPU HNSW search. It does not buildCuVS2510GPUSearchCodecindexes.PREFETCHperforms read-ahead but trusts the supplied digest;VERIFY_SHA256performs complete build-time verification.checkIntegrity()currently hashes the shared external FBIN once per segment; normal reader opening and searching do not.