Yeah not surprised. They squeeze all the performance out of a single node using the seastar framework.
Scylla – Real-Time Big Data Database
31–40 of 53 posts
Re: Scylla – Real-Time Big Data Database
#32Earlier quoted context omitted.
If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interfe…
I wouldn't write off plain old C either.
You can read more about why Scylla requires C++14 and even incorporates some aspects of C++20 here:
https://www.scylladb.com/2020/03/26/avi-kivity-at-core-c-201...
Re: Scylla – Real-Time Big Data Database
#33Earlier quoted context omitted.
If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interfe…
> Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. Based on my (admittedly limited) experience with Rust, this isn't true. Yes, you'd likely have to use "unsafe" a few times in order to implement a data…
I am a very avid proponent of rust. however, here are a few places I have had difficulty in working on custom storage engines in rust:
- uninitialized memory: it is tricky to get the semantics of uninitialized memory right. the ergonomics of the `MaybeUninit` api are frankly terrible.
- memory alignment: for O_DIRECT and other cases where memory alignment is important, it is difficult to ensure that the backing memory of Vec and other datatypes is correctly aligned, which ends up pushing you towards raw pointers.
- mmap: after considerable research, it is unclear to me whether there is a safe rust api to mmap.
- hostility to unsafe: in general, rust is easy to learn (relative to C++). however, the hostility in the community to unsafe (there are some good reasons for this, not criticizing it in general), makes it more difficult for someone without a background in C/C++ to learn how to use unsafe correctly. feels like if you ask a question about how to do unsafe you get 100 people telling you what a terrible idea that is, but for database code there is very significant performance at stake.
Re: Scylla – Real-Time Big Data Database
#34Earlier quoted context omitted.
If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interfe…
I always love your take even if I don't agree, SpaceCurve was a phenomenal system, one of the most pragmatic, high performance, easy to use MPP database systems I have ever used. We never met btw, was just a user. But I think you are wrong about Rust not having the right machinery for making high performance dbs. Two examples are Noria and Materialize https://github.com/mit-pdos/noria and it its 50k lines, in the imm…
This kind of reinforces my point though: neither Materialize nor Noria are high-performance database kernels, and they don't need to implement the high-performance I/O structures database kernels have that give Rust problems. Rust works great for server software generally, database kernels are a very specific outlier.
It is common in recent database kernel architectures to implement an entire virtual memory system in user space. This enables some great throughput optimizations. Almost all of your runtime objects are instantiated on top of this and, importantly, entities outside your process/code can write into your address space -- an invisible implicit reference. As a side effect, there are few memory references in the way Rust understands it, those outside entities don't understand or respect the object model, and some aspects of ownership, mutability, and lifetime can only be resolved at runtime and with some interesting edge cases. The model is elegant and safe, it just doesn't provide a coherent graph of classic memory references that Rust can latch onto at compile-time for safety analysis.
All good wholesome fun.
Re: Scylla – Real-Time Big Data Database
#35(Just in case some Scylla employees see this YC News post)
Sigh...
I know this sounds like a nitpick, and I know it sounds like a broken record, and I know you probably work in a different team and there's "nothing" you can do about it...
But.
I went to your website, interested in your product. I'm your target market! This site needs to impress me, and people like me.
What's the first thing that I see? The website oh-so-slowly animates, sliding down to show some TechCrunch ad.
I don't care about TechCrunch. I care about high-performance databases.
But okay, I move to close it, but "No!" says your website, helpfully overlapping it with another animated slider asking me to accept your cookie policy so that I can be tracked by your marketing group.
Fine. I close both popups, and try to read the content of your site despite the animations every paragraph or so trying to distract me from the content. As soon as I scroll too far past the animations, a stupid chat bot pops up to overlay the bottom of the content as well.
I figure I'll just go to the meat of it, some whitepaper or technical documentation. Despite their miriad flaws, PDFs are thankfully not commonly animated.
The download link for your benchmarks asks for my contact details. It's not a link. It's a sign-up form for spam. I'm not an idiot. I don't want spam. I want to read about your database.
Your marketing team actively stops your target market from looking at your products. Perhaps that's an issue you should look into, because right now there are potential customers that simply never get to find out just how amazing your technology is, because their first experience of your products makes used car salesmen look upstanding and trustworthy.
Re: Scylla – Real-Time Big Data Database
#36Earlier quoted context omitted.
If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interfe…
> Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. Based on my (admittedly limited) experience with Rust, this isn't true. Yes, you'd likely have to use "unsafe" a few times in order to implement a data…
In some databases, you neither have transparent virtual memory (like mmap or swap) nor can your runtime objects be guaranteed to exist in physical memory. In these models, references to your runtime objects are not pointers because a series of DMA operations into your address space may relocate them and your reference may also be on disk somewhere. DMA doesn't understand memory layouts or object models and has its own alignment rules, so when DMA writes to your address space, it is overwriting several potentially addressable and unrelated objects. Some databases don't even have locks to pin an object in place or arbitrate an access conflict; a scheduler decides when it is safe to dereference a particular pseudo-reference and resolves it to a transiently valid memory address. To make it a bit more complicated from the compiler's perspective, the handful of normal object pointers you do have are mapping all sorts of objects over the same memory as your other objects with different semantics, which looks like an aliasing violation at a minimum. The result is actually pretty elegant but implementation abandons any notion that an object exists at a unique memory address with a particular lifetime and knowable references. Nonetheless, it is essentially zero-copy, lock-free, and non-blocking, which is a major obsession among the performance people.
This architecture even makes C++ compilers a bit squeamish, so it is understandable why Rust looks at these things with abject horror. If you are leaning heavily on the OS facilities to do all those things for you automagically, which many open source databases do, then Rust works fine with only modest amounts of "unsafe" code. It just produces a database that is much slower.
As for the expressiveness, Rust is adding more metaprogramming facilities but it isn't there yet. C++ template metaprogramming is incredibly powerful for writing concise, correct database internals. I used to write databases in C99; it required like 5x the code to do the same thing and without the extensive compile-time correctness verification and type-safe code generation.
Re: Scylla – Real-Time Big Data Database
#37(Just in case some Scylla employees see this YC News post) Sigh... I know this sounds like a nitpick, and I know it sounds like a broken record, and I know you probably work in a different team and there's "nothing" you can do about it... But. I went to your website, interested in your product. I'm your target market! This site needs to impress me , and people like me . What's the first thing that I see? The website…
Peter Corless here from ScyllaDB's marketing team. Your feedback is 100% heard, understood & appreciated. I'll share it with the team.
The good news is that we just provided a new benchmark today and it is 100% ungated.
Scylla 4.4 vs Cassandra 4.0: https://www.scylladb.com/2021/08/24/apache-cassandra-4-0-vs-...
Also, here are a few other free and open blogs where we have benchmarked vs. competitors:
Scylla vs. DynamoDB: https://www.scylladb.com/2018/12/13/scylla-vs-amazon-dynamod...
Scylla vs. Google Cloud Bigtable: https://www.scylladb.com/2019/05/02/going-head-to-head-scyll...
Re: Scylla – Real-Time Big Data Database
#38Earlier quoted context omitted.
I was unwilling to sign up to read the actual benchmark report for the comparison to cockroachdb but it jumped out at me as odd. They solve completely different kinds of problems in my experience so I’m not surprised Scylla did better in raw throughout. That’s not interesting though. It would be just as weird for cockroach to put up a benchmark showing it outperforms in distributed sql queries. That said I’ve seen th…
Full report is posted here with no registration wall: https://www.scylladb.com/2021/01/21/cockroachdb-vs-scylla-be... And they admit that it's an odd comparison. "Obviously, the comparison is of the apples and oranges type..."
Thanks. Also, herein are some links to other non-gated benchmarks vs. Cassandra 4.0, DynamoDB and Google Cloud Bigtable:
Re: Scylla – Real-Time Big Data Database
#39Been using it since 2017 for IoT time series data. Works great, very fast.
I think the one criticism is that it seems the company has some intentional rough edges on it, in favor of their SaaS over the open source release. It used to be around backing up and managing updates long term ect. They have gotten better but their helm chart for example is very opinionated and uses custom resources in place of say a statefulset. I think their SaaS is overpriced especially compared to reserved instances but that's just me.
Also from my calls with support, they lack direction internally. One time our sales rep and customer success director argued on the phone in front of us if they could bill us for some migration work. We silently let them finish and then said we expect it to be included in our support package based on their argument.
Re: Scylla – Real-Time Big Data Database
#40Earlier quoted context omitted.
You read my mind. LOL. "Mr. Developer, can you please write your project in Rust, or __insert_your_meme_language_here__, or Javascript?"
Fromthe mouth of CockraochDB's CTO: ‶So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++.″
Wasn't that from the ScyllaDB CTO ?