Design Decisions and ScyllaDB Flavors
Design Decisions and ScyllaDB Flavors
Design decisions, an overview of the shard per core architecture (as opposed to Apache Cassandra’s thread per core), why it matters, the ecosystem and third-party integrations, and the different ScyllaDB flavors: ScyllaDB Cloud, and ScyllaDB Enterprise.
Transcript
Some of the design decisions, so ScyllaDB works in a Shard per Core architecture and what you can see in this slide is the puppy slide. So you see what happens when we have a bunch of puppies and we have plates with food and using the thread pool model that’s used in Apache Cassandra, whenever we have a job, a thread is chosen and then the thread from the thread pool runs that job; and we have a lot of context switching and that translates to what you see here, which is puppies, some of them are eating from the same bowl, some bowls are left empty and the puppies are not very happy because there’s a lot of it’s messy and some of them don’t get any food. In the Shard per Core architecture, which we use with ScyllaDB here on the right hand side, we have dedicated hardware for per shard, so we have networking and we also assign responsibility for parts of the data to different shards and that avoids the context switching problems that we have with threads. And if we translate that into puppies, you see that each puppy is eating from its own bowl and they’re way happier like that. In terms of ecosystem compatibility, so we have drivers and integrations with quite a lot of third party software. Apache Cassandra is quite a popular database and if there is a third party tool that works with Apache Cassandra, then basically it will work with ScyllaDB as well. And I won’t go into the specifics, I’ll talk a bit more about drivers I believe in the next talk, right after this, in the essentials track. Great. So I mentioned the total lower cost of ownership. We have some examples, some use cases on our website. I don’t want to go into it, but let’s maybe look, just take a look at one example: so if we compare ScyllaDB versus Cassandra, so we had a customer with 40 Cassandra nodes and they migrated to ScyllaDB, they were able to use 4 ScyllaDB nodes instead and not only did they use less nodes, they also got 2.5 less expensive, so the total cost of ownership was lower and they got better performance. So times 11 better latencies. I won’t go into details, but if you want to see some benchmarks and comparisons versus other databases, you can see them on our website. So you’re welcome to check that out. Don’t take my word for it. Okay, so ScyllaDB comes in three different flavors. I didn’t really mentioned it, but ScyllaDB is source-available software. You have the link there to our GitHub repository, you can view the code, you can add features, you can play around with that. If it’s your thing and it’s community based, so you’re welcome to check that out if that’s your thing. And also add features, send pull requests and so on, that’s one option for running ScyllaDB. The second option is ScyllaDB Enterprise, which is built on top of ScyllaDB Open source, and with ScyllaDB Enterprise you get some additional features and performance enhancements as well as our 24/7 support, which is very important to customers that are running important applications in production. That’s ScyllaDB Enterprise which can be run either on prem or on different clouds. And last but not least, we have. ScyllaDB Cloud our database as a service offering, which is recently being adopted by more and more customers. So we see more users are choosing ScyllaDB cloud. That’s our database as a managed sorry managed database as a service offering. And by choosing that basically we take care of running or administrating the database for you. Things like backups, repairs, performance, enhancements, upgrades, security and so on. You don’t have to worry about that. We take care of that for you and that can also run on multiple clouds.