Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vector database built for scalable similarity search

milvus.io

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Vector database built for scalable similarity search

#71

Post by vonmoltke »

andre-z wrote: post #66
adobrawy wrote: post #40

Earlier quoted context omitted.

In small teams, the infrastructure is often not able to be fully utilized, so performance is not an issue. However, feature richness allows this team to deliver higher-level feature faster. Think early stage startup (one or two engineers) or hairdressers-like business (they use a ready-made framework that targets a popular database and limits its feature to have a wide range of users). As a result, you can have a lot…

For small startups is better just to utilize a managed solution like Pinecone or Qdrant and do not take about infra at all.

SaaS products are infrastructure. Each different SaaS used is another piece that needs to be connected to the system and maintained; it thus becomes part of the system infrastructure. Each new SaaS piece has costs (time and money) associated with it.

That said, it's up to the individual company to decide if the added cost is worth it. Just because the cost exists doesn't mean it isn't worth it.

Re: Vector database built for scalable similarity search

#72

Post by bobvanluijt »

Somebody already mentioned it on this thread, but with Weaviate, we aim to create more end-to-end experience that can be used open source or as (hybrid-)SaaS. For example, you can store the complete data object, ANN and inverted filters (hybrid search), and optional modules for vectorization. More info about the concept behind Weaviate here: https://weaviate.io/developers/weaviate/concepts

Re: Vector database built for scalable similarity search

#73

Post by bobvanluijt »

hobofan wrote: post #60
tommoor wrote: post #28

It feels like there are an influx of "vector databases" right now, I haven't had a strong answer out of anyone on why you'd be better off using these over Redis which offers vector storage with similarity search in a battle-tested OSS solution.

One positive thing I can say about Weaviate is that it's incredibly simple to get started with it, as it handles talking to the vectorizer(s) for you, and they provide many out of the box container images for them. With that we were able to integrate a similarity search into our product very quickly. From what I can tell, its competitors generally don't do this, and you have to handle generating the embeddings and al…

Correct - this is actually a core focus of Weaviate. That's why it's not limited to only ANN but also has an inverted index, optional modules, etc.

Re: Vector database built for scalable similarity search

#74

Post by kkielhofner »

jhgg wrote: post #20
fzliu wrote: post #8

Earlier quoted context omitted.

Not yet, but this functionality should be coming soon. We're currently working on adding the capability to call third party embedding APIs directly from a Zilliz Cloud instance.

I was mulling over the idea of building keyword image search (say, with CLIP based embeddings). However I'm not really sure the cost, or whether or not this is the best solution. Do you have any case studies about large deployments of this software, and what the upper limits of scale might be?

As another commenter noted, Milvus is overkill and a "bit much" if you're learning/playing.

A good intro to the field with progression towards a full Milvus implementation could be starting with towhee[0] (which is also supported by Milvus).

towhee has an example to do exactly what you want with CLIP[1]. For icing on the cake the example notebook includes deployment of the model with Nvidia Triton Server[2], which IMO is hands down the best way to actually deploy an ML model[3].

[0] - https://towhee.io/

[1] - https://github.com/towhee-io/examples/tree/main/image/text_i...

[2] - https://github.com/triton-inference-server/server

[3] - https://news.ycombinator.com/item?id=35199418#35200266

Re: Vector database built for scalable similarity search

#75

Post by redskyluan »

qwick23 wrote: post #35

tbh. Looks like a huge overengineered legacy project. What is the clue to having all these ANN indexes in place? Is it a kinda art collection? What is the sense when you can just have HNSW in memory, with quantization, or on disk, GPU accelerated, etc. There are already better alternatives like Qdrant, which is written in Rust and super performant https://github.com/qdrant/qdrant , or Weaviate with GraphQL interface…

did you try to serve billion level vectors, on both projects you mentioned? Then you can define what is overengineered.

And what about ScaNN and GPU index? the flexibility to support multi index type is a actually a big plus

Re: Vector database built for scalable similarity search

#76

Post by txtai »

Seattle3503 wrote: post #48
dandiep wrote: post #25

I really don't want another database. I just want to have a solution built in for Postgres, and more specifically, RDS, which we use. I know there will be some extra difficulty that I will have to manage (e.g. reindexing to a new model that is outputting different embeddings), but I really don't want another piece of infrastructure. If anyone from AWS/Google/Azure is listening, please add pgvector [1] into your manag…

I'm with you there. It seems like an extension to existing DBs would be better. I would like something like this for a file based DB like sqlite.

txtai combines SQLite and Faiss to enable vector search. It also does a lot more than that.

https://github.com/neuml/txtai

Re: Vector database built for scalable similarity search

#77

Post by CuriouslyC »

bayan1234 wrote: post #51
dandiep wrote: post #25

I really don't want another database. I just want to have a solution built in for Postgres, and more specifically, RDS, which we use. I know there will be some extra difficulty that I will have to manage (e.g. reindexing to a new model that is outputting different embeddings), but I really don't want another piece of infrastructure. If anyone from AWS/Google/Azure is listening, please add pgvector [1] into your manag…

Yes exactly. My company has asked AWS if they will be adding support for pgvector for rds but they haven't been able to confirm if that will happen any time soon. If the vectors are in the same database as the tabular/structured data then text to sql applications of llm's are so much more powerful. The generative models will then be able to form complex queries to find similarity as well as perform aggregation, filte…

You could write a FDW that reads/writes to a vector database using postgres id tagged vectors. You can write to it from postgres, reference it in queries, join on it, etc. That cuts out a lot of the pain from having separate databases, the only remaining issues are additional maintenance overhead and hidden performance cliffs.

Re: Vector database built for scalable similarity search

#79

Post by vp834 »

I am not sure why Milvus is so popular. There are other pretty good options like Weaviate and Vespa - both are open source.

One important limitation of Milvus that I cannot ignore is that it does not support pre-filtering like Vespa and a few others do. Pre-filtering is critically important for use cases in e-commerce etc. where filters based on structured metadata are applied e.g. brand, category etc.

Re: Vector database built for scalable similarity search

#80

Post by snowstormsun »

simplify wrote: post #19

I only heard about vector databases along with the recent advents of AI. Assuming they've been around for a while, what were the benefits of using them over "normal" search engines (e.g. ElasticSearch)?

This is a good explanation by Niels Reimers (who created SBERT): https://www.youtube.com/watch?v=ukIYZw3uRX0
Post reply on HN