-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Enable Faiss-based vector format to index larger number of vectors in a single segment #14847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
… a single segment - Moves away from a ByteBuffer (with a 2 GB limit) to direct copying of vectors to native memory - Also simplify some other off-heap memory IO instances
This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM - one question: do we have unit tests covering this?
This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. |
@msokolov I wasn't sure about attempting to index a large amount of vector data, given that it'll take up a few GB of RAM. I've added a test for now, please let me know if I should keep it (or how to test it better). Perhaps having the test is fine, because we run Faiss tests (and only those) in a separate GH action? The test fails deterministically when added to
|
Sorry I was too vague - I didn't mean we should be testing the > 2GB case! I just wanted to make sure we had unit test coverage for these classes at all because I'm not familiar with this part of thge codebase |
- Also modify the test to make backporting easier
Yes, we have a test class that runs all tests in the We had to modify / disable a few because the format only supports float vectors and a few similarity functions.. We run these tests on each PR / commit via GH actions, see sample run from this PR, which ran:
I kind of like that we have this test, can we just mark it as "monster" so that we don't run it locally / from GH actions? I was able to run it using: ./gradlew -p lucene/sandbox -Dtests.faiss.run=true test --tests "org.apache.lucene.sandbox.codecs.faiss.*" -Dtests.monster=true -Dtests.heapsize=16g ..where it took a (relatively) long time to run:
Also, running it on |
This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. |
Description
I was trying to index a large number of vectors in a single segment, and ran into an error because of the way we copy vectors to native memory, before calling Faiss to create an index:
This limitation was hit because we use a
ByteBuffer
(backed by native memory) to copy vectors from heap -- which has a 2 GB size limitAs a fix, I've changed it to use
MemorySegment
specific functions to copy vectors (also moving away from these byte buffers in other places, and using more appropriate IO methods)With these changes, we no longer see the above error and are able to build and search an index. Also ran benchmarks for a case where this limit was not hit to check for performance impact:
Baseline (on
main
):Candidate (on this PR):
..and indexing / search performance is largely unchanged
Edit: Related to #14178