Querying MUCH slower after adding embeddings to collections

Ronan_Keaveney · 2024-04-11T11:14:52.975Z

I’ve been experimenting with switching from Weaviate to Atlas Vector Search for my vector store (200k documents, 2kB each) since they increased the max dimension size. I already had all my data stored in Mongo and only used Weaviate for vector lookups.

Since adding text embeddings to my collection, querying latency has increased 100x plus, even when I project out the embedding array. Nothing else has changed except for the embedding. A lot of the time my queries in Mongo Compass will timeout unless I put very strict filters on.

Can anyone help me figure out why this has happened please?

I’ve been considering using a separate collection just for storing embeddings & corresponding document IDs, to work around this problem, but would prefer to keep everything in the same collection if possible.

Benjamin_Flast · 2024-04-11T12:56:29.598Z

Hello @Ronan_Keaveney welcome to the community!

Are you storing the embeddings and text in the same collection that you are running Find or Aggregation queries on?

And are you saying that query latency for the Vector Search has increased or even doing regular findOne() type queries are seeing an increase in latency?

Thanks

Ronan_Keaveney · 2024-04-11T18:57:59.248Z

Thanks for the reply Benjamin!

Yeah, I originally was storing the embeddings in the same collection as my main collection, and that’s when I was seeing the massive performance issues.

I actually just created a separate for my embeddings yesterday. I’m storing:

the embedding
the text being embedded
the document ID of the corresponding document in main collection

in the separate collection. So for filtered vector search, I need to apply my metadata filters on the main collection, get all the ObjectIds which match the filter, and then vector search on the embedding collection with a query like this:

{ main_collection_document_id : {“$in”: list_of_ids}}

I thought this was a bit of a hacky workaround, but maybe this is the intended approach? It would be a lot cleaner to store the embeddings in the same collection as all the filtering metadata, but I guess this works.

As for your question about findOne(), I actually didn’t try that, and I’ve transitioned to the separate embedding collection approach now. I did try using a limit of 3 documents in my query, and this still timed out, so I guess findOne would do the same.

Would you say storing the embeddings in a separate collection to the metadata used for filtering would be the best approach then?

Thanks
Ronan

Ronan_Keaveney · 2024-04-12T21:41:23.724Z

@Benjamin_Flast tagging in case you don’t get notified for reply

Michael_Lynn · 2024-07-29T15:28:58.109Z

Yes - storing embeddings makes sense when you’re querying your data often enough without the requirement for the embeddings. The data modeling mantra “Data that is accessed together, should be stored together.” still holds true. Many applications leverage operational data without the need to access or reference embeddings… if this is the case, separating makes sense.

Azri · 2024-07-29T16:51:02.737Z

Going over the thread, I realized that the original issue hasn’t been addressed directly. Should it be possible to have the embeddings in the same collection without the performance hit? If yes, how should it be done?