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

How We Built a Vectorized SQL Engine

cockroachlabs.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: How We Built a Vectorized SQL Engine

#51

Post by aloknnikhil »

tom_mellior wrote: post #49
aloknnikhil wrote: post #28

Earlier quoted context omitted.

For me, the issue with GC never has been about how long it runs for. It's been about the unpredictability of when it can kick in. Granted a malloc can be unpredictable too (albeit very very rarely), but at least you know a malloc is the only time your process could stall waiting for memory. Databases make extensive use of scratch space for undo logs and redo logs and especially while processing JOINs. It's tremendous…

> With C/C++/Rust, you'd pipeline the query stages to malloc/free that space outside the hot path to minimize query response times. I don't understand why you seem to assert that GC'd languages would force you to put allocations on the hot path. Surely in Go you can also allocate that space elsewhere?

I was primarily referring to the free on the hot path. GCd languages don't force any allocation paradigms. But due to the unpredictability of the GC, you could be in the middle of a query execution and the GC can kick in. With C/C++/Rust, you're free to maintain your own a allocator that could have a buffer pool of pages that can be recycled and freed when the database is idle. Under a large load, the micro spikes in latency can have an avalanche effect that leads to a build up of queries. I've dealt with customer cases where the MySQL/InnoDB lock manager caused connection spikes due to a brief (< 10 us) global write lock taken while the system was under load.

Re: How We Built a Vectorized SQL Engine

#52

Post by mumblemumble »

jandrewrogers wrote: post #43
mumblemumble wrote: post #38

Earlier quoted context omitted.

So, before we theorize that Cockroach can't possibly be fast enough to meet anyone's needs, perhaps we should look at some performance figures? I haven't ever touched it myself, but, if the benchmarks that Cockroach Labs posts on their blog are to be believed, it's pretty respectable for what it is.

You are misrepresenting what was written. Most databases don't need to be optimal to be useful, merely adequate, and few attempt to be optimal in any kind of absolute sense. I still use PostgreSQL regularly and it unambiguously falls into this "far from optimal" category. However, as data velocity and volume grow, optimization of absolute performance and hardware efficiency has an increasingly large impact on the cos…

This seems to me, though, like a spot where the application of Knuth's law is critical. It's not enough to demonstrate that X is slower than it could be, you have to demonstrate that it is that, and that this is also having an appreciable impact on the overall behavior of the system.

So, given that CockroachDB is a distributed system, I'd want to start by seeing some measurements to demonstrate that GC overhead is having a bigger impact than, say, network latency.

Re: How We Built a Vectorized SQL Engine

#53

Post by tom_mellior »

aloknnikhil wrote: post #51
tom_mellior wrote: post #49

Earlier quoted context omitted.

> With C/C++/Rust, you'd pipeline the query stages to malloc/free that space outside the hot path to minimize query response times. I don't understand why you seem to assert that GC'd languages would force you to put allocations on the hot path. Surely in Go you can also allocate that space elsewhere?

I was primarily referring to the free on the hot path. GCd languages don't force any allocation paradigms. But due to the unpredictability of the GC, you could be in the middle of a query execution and the GC can kick in. With C/C++/Rust, you're free to maintain your own a allocator that could have a buffer pool of pages that can be recycled and freed when the database is idle. Under a large load, the micro spikes in…

> But due to the unpredictability of the GC, you could be in the middle of a query execution and the GC can kick in.

Yes, that is a possibility. Typically there are two ways to deal with this in a GC'd language: (a) You know that GC is only triggered by certain operations that might allocate, and you avoid those operations in your critical hot section, or (b) you know how to disable the GC temporarily, while you are in that critical hot section. For Go the latter is apparently done by calling this function: https://golang.org/pkg/runtime/debug/#SetGCPercent

I'm not a Go developer myself, but I imagine people developing such low-latency software in Go know about this.

Re: How We Built a Vectorized SQL Engine

#55

Post by valyala »

snark42 wrote: post #29
echelon wrote: post #21

Earlier quoted context omitted.

I'm shocked that they chose a garbage-collected language to implement a database with. Golang is great for building servers, but this is domain with potentially much greater resource constraints. How do they deal with GC pause? I'm sure that they have an answer, but they'd have so much more latitude if they had the facility to reason about this from the ground up. They've sort of painted themselves into a corner now.…

InfluxDB is written in Golang as well. It's rather performant and scales out nicely, given my experience I don't think I'd consider Golang a big concern.

There is VictoriaMetrics, which is also written in Go and shows much higher performance numbers than InfluxDB, especially on high cardinality data. See [1], [2] and [3].

[1] https://medium.com/@valyala/measuring-vertical-scalability-f...

[2] https://medium.com/@valyala/insert-benchmarks-with-inch-infl...

[3] https://medium.com/@valyala/high-cardinality-tsdb-benchmarks...

Re: How We Built a Vectorized SQL Engine

#56

Post by dkersten »

beders wrote: post #15
ticmasta wrote: post #14

Earlier quoted context omitted.

Why is this sub-optimal? People may not like Cockroaches but they definitely have a reputation for durability, which isn't a bad mental link for a database company. It also provides an identity & personality which is so often missing from modern companies. Maybe they've found they get more from those who really like it than those who really hate it (or maybe they just like it themselves).

It still has a negative connotation. That's unavoidable. People don't like cockroaches. From a marketing point of view, it is a very bad name. Unless the perception of cockroaches changes, which is rather unlikely.

I’m not a paying customer so my anecdote maybe isn’t useful, but there’s so many databases that typically I just brush them off, but this one grabbed my attention because of the name.
Post reply on HN