$vectorSearch performance

I have a collection with 2.75million embeddings where I have also created MongoDB Atlas vector search index. I am using OpenAI embedding model “text-embedding-ada-002” to embed and query this vector store using Llamaindex node.js library. My MongoDB cluster is currently on M30, I am currently trying to assess vectorsearch performance. Even for top similarity of 2 items, a query takes about 30 seconds to return a response. Am I missing something, or is this the expected performance for such a cluster with that amount of data?

2.75 million is a lot. I’ll probably have 1/4 of that once I’ve written all the embeddings for my use case.

I’d strongly encourage you to utilize the $filter field as much as you can - this helped reduce the runtime significantly for me and I’m sure it would for you as well.

As an example, lets say you have image embeddings for pictures of animals. Before they are written, each embedding runs through a classifier that determines the animal in the image (i.e. “dog”, “cat”, “giraffe”).

Likewise, when performing a vector search with a target image, the target image itself runs through the same classifier to determine the type of animal. This classification is added to the $filter portion of the Vector Search query.

When performing the search, Mongo doesn’t have to check through every entry of the collection - only the ones with the matching classification. What might be 2.75m could turn out to be something like 100 or 200k.

Hope this helps.

Hello @Umit_Cakmak apologies for the delay here.

The latency that you’re seeing is not expected but it is most likely being driven by insufficient Memory for your workload. In order to achieve the best level of performance with Atlas Vector Search the entire index must fit into memory. The easiest way to ensure this is by looking at the built index on in the Index Configuration tab in the cluster which should show you the total size of the index in GB and then provisioning a “Search Node” that sufficient memory to fit the entire index in memory.

Please let me know if you have any questions and feel free to reach out to me directly at benjamin.flast@mongodb.com - apologies again for the delayed response.

Hi @Benjamin_Flast just shot you an email about this!