Scylla – Real-Time Big Data Database(scylladb.com)
scylladb.com
Scylla – Real-Time Big Data Database
https://www.scylladb.com/
52 comments
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...
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...
To also provide some constructive feedback:
A good point of comparison is this website: https://www.jetbrains.com/idea/
It's also a product targetted at technical people, including people working at startups and also large enterprise.
No popups.
When you click the community edition download link -- bam -- it is immediately downloading! No form to fill in.
I don't even use their tools much any more, except for the Rust plugin. Nonetheless, I read through their "what's new" release notes, even for Java, because it is so well presented: https://www.jetbrains.com/idea/whatsnew/
I don't have to sit through an hour-long YouTube video watching some guy introducing some other guy I don't care about for five minutes. https://knowyourmeme.com/memes/the-wadsworth-constant
Instead they have GIFs showing short, to-the-point snippets of exactly what each feature does. Note that these don't animate by default! You have to click them to play the clip. I love that. They're helpful without being distracting while I'm reading nearby text.
It also gives you an idea of what the product looks like in actual use.
You have no idea how much crap people wade through to find this! I often spend hours googling terms like "Product X Screenshot", "Product X real-world", "Product X tutorial" in the futile attempt to just find out what the heck to expect. Is it a green-screen terminal app kept alive like some sort of crime against nature? Is it a web application? Does it come with a Windows-only GUI? If so, is it at least a usable one? Does it have command-line tools? PowerShell? Tab-complete?
You go to a site like JetBrains, and you see exactly that! Real-world code being manipulated, showing you the product in all its glory.
So show this! Show ScyllaDB doing something. Don't just talk about how it's 47% more snazzy than a competing product I haven't used.
Show it doing a schema change nearly instantly on a terabyte of data, or whatever. But show me the product, or I walk away until I find a website that isn't afraid of letting me see what they're selling...
A good point of comparison is this website: https://www.jetbrains.com/idea/
It's also a product targetted at technical people, including people working at startups and also large enterprise.
No popups.
When you click the community edition download link -- bam -- it is immediately downloading! No form to fill in.
I don't even use their tools much any more, except for the Rust plugin. Nonetheless, I read through their "what's new" release notes, even for Java, because it is so well presented: https://www.jetbrains.com/idea/whatsnew/
I don't have to sit through an hour-long YouTube video watching some guy introducing some other guy I don't care about for five minutes. https://knowyourmeme.com/memes/the-wadsworth-constant
Instead they have GIFs showing short, to-the-point snippets of exactly what each feature does. Note that these don't animate by default! You have to click them to play the clip. I love that. They're helpful without being distracting while I'm reading nearby text.
It also gives you an idea of what the product looks like in actual use.
You have no idea how much crap people wade through to find this! I often spend hours googling terms like "Product X Screenshot", "Product X real-world", "Product X tutorial" in the futile attempt to just find out what the heck to expect. Is it a green-screen terminal app kept alive like some sort of crime against nature? Is it a web application? Does it come with a Windows-only GUI? If so, is it at least a usable one? Does it have command-line tools? PowerShell? Tab-complete?
You go to a site like JetBrains, and you see exactly that! Real-world code being manipulated, showing you the product in all its glory.
So show this! Show ScyllaDB doing something. Don't just talk about how it's 47% more snazzy than a competing product I haven't used.
Show it doing a schema change nearly instantly on a terabyte of data, or whatever. But show me the product, or I walk away until I find a website that isn't afraid of letting me see what they're selling...
Good point on the video-first strategy. We're talking more about this internally.
Also: For Scylla Open Source downloads aren't gated -- no name or email address neeeded. We do need to ask what platform you're running on, because the way you deploy to each is different. e.g.,
https://www.scylladb.com/download/?platform=aws#open-source
Also: For Scylla Open Source downloads aren't gated -- no name or email address neeeded. We do need to ask what platform you're running on, because the way you deploy to each is different. e.g.,
https://www.scylladb.com/download/?platform=aws#open-source
These are classic enterprise software lead gen tactics and somewhat hint at the future you might expect should you do business with them.
Hopefully this was a poorly thought out gate and not a signal that they’ve gone full enterprise tactics.
Hopefully this was a poorly thought out gate and not a signal that they’ve gone full enterprise tactics.
Welcome to modern web
Been 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.
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.
So an open exchange of ideas, and some free assistance. Sounds like it was a good outcome for you. :)
The benchmarks against DynamoDB, Bigtable, & CockroachDB [1] appear quite impressive - anyone have real world experience that can attest to these claims of improved performance and reduced cost?
> Scylla vs DynamoDB – Database Benchmark
> 20x better throughput in the hot-partition test
> Scylla Cloud is 1/7 the expense of DynamoDB when running equivalent workloads
> Scylla Cloud: Average replication latency of 82ms. DynamoDB: Average latency of 370ms.
> Scylla vs Bigtable – Database Benchmark
> Scylla Cloud performs 26X better than Google Cloud Bigtable when applied with real-world, unoptimized data distribution
> Google BigTable requires 10X as many nodes to accept the same workload as Scylla Cloud
> Scylla Cloud was able to sustain 26x the throughput, and with read latencies 1/800th and write latencies less than 1/100th of Cloud Bigtable
> Scylla vs CockroachDB – Database Benchmark
> Loading 10x the data into Scylla took less than half the time it took for CockroachDB to load the much lesser dataset.
> Scylla handled 10x the amount of data.
> Scylla achieved 9.3x the throughput of CockroachDB at 1/4th the latency.
[1] https://www.scylladb.com/product/benchmarks/
> Scylla vs DynamoDB – Database Benchmark
> 20x better throughput in the hot-partition test
> Scylla Cloud is 1/7 the expense of DynamoDB when running equivalent workloads
> Scylla Cloud: Average replication latency of 82ms. DynamoDB: Average latency of 370ms.
> Scylla vs Bigtable – Database Benchmark
> Scylla Cloud performs 26X better than Google Cloud Bigtable when applied with real-world, unoptimized data distribution
> Google BigTable requires 10X as many nodes to accept the same workload as Scylla Cloud
> Scylla Cloud was able to sustain 26x the throughput, and with read latencies 1/800th and write latencies less than 1/100th of Cloud Bigtable
> Scylla vs CockroachDB – Database Benchmark
> Loading 10x the data into Scylla took less than half the time it took for CockroachDB to load the much lesser dataset.
> Scylla handled 10x the amount of data.
> Scylla achieved 9.3x the throughput of CockroachDB at 1/4th the latency.
[1] https://www.scylladb.com/product/benchmarks/
We just posted this today. Latest Cassandra 4.0 vs. Scylla 4.4. Note: Cassandra 4.0 is a HUGE improvement over Cassandra 3.11. But we're still many times faster:
https://www.scylladb.com/2021/08/24/apache-cassandra-4-0-vs-...
https://www.scylladb.com/2021/08/24/apache-cassandra-4-0-vs-...
[deleted]
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 the value Scylla brings in its core value prop, replacing Cassandra. It’s real good at that.
That said I’ve seen the value Scylla brings in its core value prop, replacing Cassandra. It’s real good at that.
They're technically both KV stores capable of offering you a tabular data model with multi-regional replication and leaderless horizontal scaling.
CockroachDB is focused on consistency with full SQL support while ScyllaDB focuses on availability with high-performance.
CockroachDB is focused on consistency with full SQL support while ScyllaDB focuses on availability with high-performance.
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:
https://news.ycombinator.com/item?id=28297382
https://news.ycombinator.com/item?id=28297382
Yes, Scylla does what it says. Used it in a prior adtech company and it beat everything else at that time for a very intensive key/value workload that also needed multi-regional replication.
The adtech industry also uses Aerospike heavily but that (at the time) had many replication data model issues compared to Scylla/Cassandra.
The adtech industry also uses Aerospike heavily but that (at the time) had many replication data model issues compared to Scylla/Cassandra.
We (@zenlyapp) have been using it for 4 years, it is as fast as advertised, it’s insane. We personally benchmarked the 10x of Cassandra.
It is interesting in that this is here on the front page and an old article about Discord moving to Cassandra is also here considering Discord went from Cassandra to Scylla I beleive.
I posted this because I'm interested to hear from anyone using it - how has it worked out for you?
I note it's written in C++ which is a bit of a surprise - I'd expected Rust or Golang.
Interesting as well is is AGPL - licensing is always contentious:
https://github.com/scylladb/scylla/blob/master/LICENSE.AGPL
I note it's written in C++ which is a bit of a surprise - I'd expected Rust or Golang.
Interesting as well is is AGPL - licensing is always contentious:
https://github.com/scylladb/scylla/blob/master/LICENSE.AGPL
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 interferes with core design elements of high-performance database kernels. In addition to a significant loss of performance, it introduces operational edge cases you don't have to deal with in non-GC languages.
Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. 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.
C++ is just exceptionally ergonomic for writing high-performance database kernels compared to the alternatives at the moment.
Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interferes with core design elements of high-performance database kernels. In addition to a significant loss of performance, it introduces operational edge cases you don't have to deal with in non-GC languages.
Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. 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.
C++ is just exceptionally ergonomic for writing high-performance database kernels compared to the alternatives at the moment.
> Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. 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.
None of that sounds right to me.
More likely the developers already know C++, there's already a lot of KV stores built in C++, and Rust is a relatively new player. Scylla was released in 2015, Rust hit 1.0 in 2015, seems obvious why Scylla didn't go with Rust.
edit: Yep, from further down
> 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++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
None of that sounds right to me.
More likely the developers already know C++, there's already a lot of KV stores built in C++, and Rust is a relatively new player. Scylla was released in 2015, Rust hit 1.0 in 2015, seems obvious why Scylla didn't go with Rust.
edit: Yep, from further down
> 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++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
> 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 database system in Rust, but you would only need to do this for certain types of low-level data structures. The uses of those data structures—which would represent the majority of your code—would almost certainly be written in safe Rust. Don't throw the baby out with the bathwater.
I also contest the assertion that Rust is "less expressive" than C++; I have found Rust to be very expressive and concise for such a safe language. But I also don't have a ton of experience with either one, so don't take my word for that.
The real answer as to why Scylla does not use Rust is that the language simply wasn't very mature when they started. It also helps that there are significantly more engineers that know C++ than those that know Rust.
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 database system in Rust, but you would only need to do this for certain types of low-level data structures. The uses of those data structures—which would represent the majority of your code—would almost certainly be written in safe Rust. Don't throw the baby out with the bathwater.
I also contest the assertion that Rust is "less expressive" than C++; I have found Rust to be very expressive and concise for such a safe language. But I also don't have a ton of experience with either one, so don't take my word for that.
The real answer as to why Scylla does not use Rust is that the language simply wasn't very mature when they started. It also helps that there are significantly more engineers that know C++ than those that know Rust.
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.
- 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.
> - uninitialized memory: it is tricky to get the semantics of uninitialized memory right. the ergonomics of the `MaybeUninit` api are frankly terrible.
Agreed. There's some unstable APIs that will help, but it's not great today.
> mmap
There is no possible way to expose raw mmap safely because the data under the hood can change out from under you. Whatever it is you're doing you'd want to wrap that. For example, a &[u8] could be safe, but not if you then did `str::from_utf8`. So you just have to make sure that mmap'd data is treated very carefully and doesn't get exposed across a safe boundary.
> - hostility to unsafe:
Same feeling here and I know many others feel the same way. The community can overreact to things, it is what it is.
Agreed. There's some unstable APIs that will help, but it's not great today.
> mmap
There is no possible way to expose raw mmap safely because the data under the hood can change out from under you. Whatever it is you're doing you'd want to wrap that. For example, a &[u8] could be safe, but not if you then did `str::from_utf8`. So you just have to make sure that mmap'd data is treated very carefully and doesn't get exposed across a safe boundary.
> - hostility to unsafe:
Same feeling here and I know many others feel the same way. The community can overreact to things, it is what it is.
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.
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.
are there any examples of this technique used in open source projects? I'd be interested to look at the code and see what you mean in greater detail.
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 immediate codebase, there are 40 uses of unsafe.
In Materialize's 125k of Rust, there are 76 direct uses of unsafe.
https://github.com/MaterializeInc/materialize
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 immediate codebase, there are 40 uses of unsafe.
In Materialize's 125k of Rust, there are 76 direct uses of unsafe.
https://github.com/MaterializeInc/materialize
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.
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.
Not sure proves your point, but maybe doesn't disprove your point strongly enough. I am not qualified to argue from experience about how Rust is ideally suited in the ways you think it is not. But from everything I have seen, it can do a whole lot of what C++ is also good at. Rust safety is not all or nothing and a codebase could definitely prioritize ergonomics over correctness.
Two things that I saw in the last couple weeks that might start to sway you.
https://github.com/sslab-gatech/Rudra#readme
GhostCell: Separating Permissions from Data in Rust https://www.youtube.com/watch?v=jIbubw86p0M
Even unsafe Rust can be as ergonomic as C++. But that unsafety can be mediated, moderated and controlled.
Two things that I saw in the last couple weeks that might start to sway you.
https://github.com/sslab-gatech/Rudra#readme
GhostCell: Separating Permissions from Data in Rust https://www.youtube.com/watch?v=jIbubw86p0M
Even unsafe Rust can be as ergonomic as C++. But that unsafety can be mediated, moderated and controlled.
At QuestDB we chose zero-GC Java for 80% of the code base, which resulted in superior performance on ingestion compared to the alternatives.
Zig might be a good option -- eventually, once it's past 1.0.
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...
https://www.scylladb.com/2020/03/26/avi-kivity-at-core-c-201...
Quoting the interview with ScyllaDB CTO, Avi Kivity ( https://www.scylladb.com/2020/06/30/ask-me-anything-with-avi... )
> Q: Would you implement Scylla in Go, Rust or Javascript if you could?
> Avi: Good question. I wouldn’t implement Scylla in Javascript. It’s not really a high-performance language, but I will note that Node.js and Seastar share many characteristics. Both are using a reactor pattern and designed for high concurrency. Of course the performance is going to be very different between the two, but writing code for Node.js and writing code for Seastar is quite similar.
> Go also has an interesting take on concurrency. I still wouldn’t use it for something like Scylla. It is a garbage-collected language so you lose a lot of predictability, and you lose some performance. The concurrency model is great. The language lacks generics. I like generics a lot and I think they are required for complex software. I also hear that Go is getting generics in the next iteration. Go is actually quite close to being useful for writing a high-performance database. It still has the downside of having a garbage collector, so from that point-of-view I wouldn’t pick it.
> If you are familiar with how Scylla uses the direct I/O and asynchronous I/O, this is not something that Go is great at right now. I imagine that it will evolve. So I wouldn’t pick Javascript or Go.
> However, the other language you mentioned, Rust, does have all of the correct characteristics that Scylla requires. Precise control over what happens. It doesn’t have a garbage collector so it means that you have predictability over how much time your things take, like allocation. You don’t have pause times. And it is a well-designed language. I think it is better than C++ which we are currently using. 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++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
> Q: Would you implement Scylla in Go, Rust or Javascript if you could?
> Avi: Good question. I wouldn’t implement Scylla in Javascript. It’s not really a high-performance language, but I will note that Node.js and Seastar share many characteristics. Both are using a reactor pattern and designed for high concurrency. Of course the performance is going to be very different between the two, but writing code for Node.js and writing code for Seastar is quite similar.
> Go also has an interesting take on concurrency. I still wouldn’t use it for something like Scylla. It is a garbage-collected language so you lose a lot of predictability, and you lose some performance. The concurrency model is great. The language lacks generics. I like generics a lot and I think they are required for complex software. I also hear that Go is getting generics in the next iteration. Go is actually quite close to being useful for writing a high-performance database. It still has the downside of having a garbage collector, so from that point-of-view I wouldn’t pick it.
> If you are familiar with how Scylla uses the direct I/O and asynchronous I/O, this is not something that Go is great at right now. I imagine that it will evolve. So I wouldn’t pick Javascript or Go.
> However, the other language you mentioned, Rust, does have all of the correct characteristics that Scylla requires. Precise control over what happens. It doesn’t have a garbage collector so it means that you have predictability over how much time your things take, like allocation. You don’t have pause times. And it is a well-designed language. I think it is better than C++ which we are currently using. 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++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
I'd be careful with the idea of predictability and allocation. The best way to get predictabile performance is to avoid dynamic allocation altogether. The next best is to do your own allocation (slab-base per request, memory pools, etc.). General purpose dynamic memory management is a bin-packing problem (NP-hard).
Only on Hackernews would somebody be surprised that high-performance system software would be written in C++...
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++.″
It was a joke, to capture the sentiment here in HN. Rust is awesome, and most people know it. My point was that people will focus more often on which language is used, rather than the technical design, performance, etc...
Right, meaning, no, the CTO would not be "surprised" that C++ was a candidate for a high performance system. C++ is the defacto, and Rust would be a "new" option.
I think the main reason it's in C++ is because of its async executor, Seastar. There's a similar Rust project called Glommio but seems still very early.
Glommio was created by Glauber Costa, one of the early contributors to Seastar (and Scylla). The resemblance between the two is not coincidence.
https://glaubercosta-11125.medium.com/c-vs-rust-an-async-thr...
Seastar is sort of a C++-ification of node.js. Now that C++20 has coroutines, I wonder if those could have been used instead of all that chained method stuff.
Seastar already uses coroutines, however coroutines without Seastar reactor (and all the utilities for IO) are useless by themselves. You still need a way to schedule what's being done when.
Hmm ok I haven't looked at Seastar in a while, but it used to depend on Node-like control inversion where you'd pass an explicit lambda to each action, telling the action what to do next. That meant unwinding the handler for a given event into a bunch of nested lambdas. Coroutine would let you write them in a more traditional sequential style, where you'd have a return to the scheduler whenever something could block. Yes you have to write a layer of async io under everything, but that's how any OS works, more or less.
We're using it with several customers: fast, reliable, straightforward.
[deleted]
Yeah not surprised. They squeeze all the performance out of a single node using the seastar framework.
Whenever I hear Scylla mentioned, I often wonder: where is Charybdis? They do work as a team, after all. :-)
Charybdefs is our fault injection filesystem. Though it's based in Thrift, the ol' API that predated CQL.
https://github.com/scylladb/charybdefs
More modern is Project Circe, our efforts to make Scylla into an even more monstrous database:
https://www.scylladb.com/2021/01/12/making-scylla-a-monstrou...
https://github.com/scylladb/charybdefs
More modern is Project Circe, our efforts to make Scylla into an even more monstrous database:
https://www.scylladb.com/2021/01/12/making-scylla-a-monstrou...
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.