Live data from Hacker News

Vector search just got up to 10x faster and vertically scalable

pinecone.io

51–54 of 54 posts

Re: Vector search just got up to 10x faster and vertically scalable

#51
post #18

Earlier quoted context omitted.

This is incorrect.

Yeah, what's this landing page about? https://www.pinecone.io/managed-faiss/

That's a very old and experimental page -- hence the "early access" mentions. Glad you pointed it out so we can delete it.

Re: Vector search just got up to 10x faster and vertically scalable

#53
post #37
post #23

Earlier quoted context omitted.

Bigger machine doesn't automatically mean higher performance. The code needs to scale with the increased number of cores, has share-nothing or share-very-little approach to avoid contention, and uses efficient data structure to utilize the increased memory.

Larger disk space does help effortlessly scale storage in single-node systems, but I agree with you that shared nothing (and/or shared something) is a necessary step for extracting maximum performance on a larger machine. When it comes to distributed architectures, shared nothingness is important as well. The decoupling of storage from compute and stateless from stateful helps minimize resource allocation when it com…

Just having "moar disk!" ≠ "scalability." Because unlike running single-thread on a shard-per-core [or hyperthread] basis, aligning NUMA memory to those cores, etc., there's no way to make your storage "shared-nothing."

At ScyllaDB we've put years of non-trivial effort into IO scheduling to optimize it for large amounts of storage. You also need to consider the type of workload. Because optimizing for reads, writes, or mixed workloads are all different beasties.

More here:

https://www.scylladb.com/2022/08/03/implementing-a-new-io-sc...

Re: Vector search just got up to 10x faster and vertically scalable

#54
post #23

Earlier quoted context omitted.

Bigger machine doesn't automatically mean higher performance. The code needs to scale with the increased number of cores, has share-nothing or share-very-little approach to avoid contention, and uses efficient data structure to utilize the increased memory.

Why would search queries have contention with each other? Surely it's in the domain of embarrassingly parallel.

Disk IO needs concurrency. And you're back to Little's Law.
Post reply on HN