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

Rewriting a high performance vector database in Rust

pinecone.io

Post reply on HN
Print view View original

151–157 of 157 posts

Re: Rewriting a high performance vector database in Rust

#151

Post by smitty1e »

code_biologist wrote: post #123
jiggawatts wrote: post #114

Earlier quoted context omitted.

Standard row-oriented databases store columns on disk like so: ABCABCABCABC Vector databases store them like this: AAAABBBBCCCC This allows faster queries if you just need one (or a few) columns, because unrelated columns don’t have to be processed at all. Caches are more efficient, vector CPU instructions can be used, etc… The downside is that random single row access is more expensive because a row has to be reasse…

You're describing a column store there, not a vector store.

I always thought a columnar store was a series of key:value dictionaries that could produce an RDBMS table result on demand.

Re: Rewriting a high performance vector database in Rust

#152

Post by dureuill »

lupire wrote: post #79
dymk wrote: post #57

Earlier quoted context omitted.

It takes longer to learn how to use C++ to the same level of proficiency and correctness compared to Rust, in my experience. It's harder to write an incorrect program in Rust.

What are the main correctness risks in C++ if you just never use a raw pointer?

how do you observe data you don't own if you never use a raw pointer or reference?

if you use shared ptr for this:

1. shared ptrs aren't made for this use case, they're for shared ownership 2. why using C++ at all if it means reducing its performance to an (atomatocally) performance counted language? Rust allows for much more performance with its safe borrowed references.

That also not what the CPP core guidelines, that are supposed to define modern C++, prescribe: For general use, take T* or T& arguments rather than smart pointers[0]. This rule incurs the risk of use after free if the returned reference is kept for too long by the caller. The rules for reference validity are non trivial (eg you returned a reference to an item of a vector, if you push into your vector you might invalidate the reference), so this is a significant source of bugs even in modern C++.

if you don't use shared ptr or references/pointers for this i'm curious as to which mechanism you're using to observe non owning data

[0]: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

Re: Rewriting a high performance vector database in Rust

#153

Post by jiggawatts »

smitty1e wrote: post #151
code_biologist wrote: post #123

Earlier quoted context omitted.

You're describing a column store there, not a vector store.

I always thought a columnar store was a series of key:value dictionaries that could produce an RDBMS table result on demand.

That’s a specific physical implantation. If using a key-value storage system then the keys are:

    Row    store: “table id; row id; column id”
    Column store: “table id; column id; row id”
The difference is the order used to sort the data in storage.

In reality, most column store systems use a more complex partitioning scheme with row groups and the like…

Re: Rewriting a high performance vector database in Rust

#154

Post by menaerus »

TehCorwiz wrote: post #146
menaerus wrote: post #145

Earlier quoted context omitted.

You seem to come from a point as if I don't care about the intricate knowledge of programming languages or as if I don't care about learning how different languages manage to solve the same problem but from a different angle or with a different approach. I really do. What I don't see here in this article is none of that with some very loose arguments around picking Rust vs some other system programming language. Very…

This isn't a technical article. This is an article about about an organization making a business decision based on broad goals, not specific tasks. They explained the technical and human requirements they wanted to optimize for and explained the other options they had available to them and why they chose the way they did. Then they explained their experience. This article is for managers, team leads, directors, to he…

My comment would have been dismissive if I had not provided the rationale which I did and I still stand by my original point. Article provided no or whatsoever evidence why rewriting a vectorized database engine in Rust would solve any problems that could not have been solved with the original implementation language (C++ with Python front-facing API). It reads like a wasted effort providing no strong grounds for doing so.

> This isn't a technical article. This is an article about about an organization making a business decision based on broad goals, not specific tasks. They explained the technical and human requirements they wanted to optimize for and explained the other options they had available to them and why they chose the way they did. Then they explained their experience. This article is for managers, team leads, directors, to help them navigate similar business decisions.

Wow. A text building upon loose arguments around the AVX-512 instruction sets, memory layouts, memory footprint, garbage collection, asynchronous execution, parallel processing and benchmarking is not a technical article but a guide for businesses?

> First of all, Python is a garbage collected language, which means it can be extremely slow for writing anything high performance at scale.

False. Time spent on the frontend API (be it Python connector through JDBC or ODBC) is literally nonexistent to the time spent in the engine actually crunching the analytical workload. Python seems to work just fine for dozens of database engine companies around.

> In addition, it’s challenging to find developers with experience in both Python and C++.

Even if that had been true, which is highly unlikely given the popularity and age of both C++ and Python, finding seasoned Rust developers is easier? C++ and Python is a pretty much regular combination from my experience but even if Python is lacking, devs with C++ background will pick up Python in no time. Anyone basically will.

> we wanted to find some way to unify our code base

I failed to understand the reasons for that unification. However, now that the codebase will be unified, it will be interesting to see in what languages will the ecosystem be developed. Python? Rust?

> while achieving the performance predictability we needed.

If "code unification" had been the only requirement, for which I don't see any strong arguments, there's probably no better language than C or C++ at this point to fit such a task. Rust actually isn't that predictable when it comes to code generation.

> We knew that C++ was harder to scale and maintain high quality as you build a dev team

Again, there's no argument which would support that Rust will somehow excel C++ in this point? Anyway I am pretty much sure that the way of things are quite the opposite. Building a high-performing team in a C++ still at this point is a much better bet.

I could go further and further dissecting the article but I will stop here. Your impression is that they explained all their decisions thoroughly providing a ground for other business decision-makers and I have to disagree with that. Quality of the content is low, arguments are almost non-existent and very loose. All I see is a biased presentation. Or one may say low-quality Rust pitch.

Not to mention how absurd is to _rewrite_ the whole database engine in another language just because. Too bad that the engine isn't open-source so that we can actually see how it goes along the way.

Re: Rewriting a high performance vector database in Rust

#155

Post by Omin »

saghm wrote: post #137
krona wrote: post #91

Earlier quoted context omitted.

The results are a trade-off between sparse or having false positives. Rust just takes the other side of the trade-off, and will reject valid programs. Hence why the unsafe keyword exists, and why tools like Miri ( https://github.com/rust-lang/miri ) exist specifically for rust.

> Rust just takes the other side of the trade-off, and will reject valid programs This has always been such a weird claim to me because it's not clear to me what's meant by "valid". My instinct is that it would be hard to define valid in a way without making most languages either accept some invalid programs or reject some valid ones (the exception being defining "valid" as "anything that language X accepts", but tha…

That definition of what is valid or not depends on the type of checker. When you're talking about Rust's borrow checker, then you can take any property that it checks for, such as "there are no aliasing mutable references" or "any variable that is read from has been initialized" and build an example for it that would be correct, but is rejected by the borrow checker.

Here is an example where a variable is definitely initialized, but it will be rejected.

  fn main() {
      let foo;
      if true {
          foo = 1;
      }
    
      println!("{}", foo);
  }

Re: Rewriting a high performance vector database in Rust

#156

Post by smitty1e »

jiggawatts wrote: post #153
smitty1e wrote: post #151

Earlier quoted context omitted.

I always thought a columnar store was a series of key:value dictionaries that could produce an RDBMS table result on demand.

That’s a specific physical implantation. If using a key-value storage system then the keys are: Row store: “table id; row id; column id” Column store: “table id; column id; row id” The difference is the order used to sort the data in storage. In reality, most column store systems use a more complex partitioning scheme with row groups and the like…

I mean, sure. But even DNS is a key:value store, or would you say that's over-simplifying?

Re: Rewriting a high performance vector database in Rust

#157

Post by likeabbas »

AtlasBarfed wrote: post #141
likeabbas wrote: post #6

Earlier quoted context omitted.

Memes typically have some basis in reality. If your project reaches a point where it could benefit from fearless concurrency or better memory control, Rust is probably your best bet at the moment. I could see huge benefits from Kafka and Cassandra being re-written in Rust.

20 year JVM programmer and current Cassandra user. Rust rewrite of cassandra, if it could reach feature parity with 4.0, would be a good thing. (C++ port already sortof exists with ScyllaDB but they haven't reached feature parity yet)

Agreed. Java is great for general purpose programming, I just think everyone can benefit from their systems tools being a little more lean. I can’t tell you how often my teams deal with trying to tune the GC
Post reply on HN