By now, you’ve probably heard that ScyllaDB University will be back in session on December 1 (this Thursday!). You can look forward to hours of new content – whether you’re looking to jumpstart your NoSQL adoption or master the latest ScyllaDB capabilities.
But what many people don’t realize is that the candid roundtable discussion following the sessions is actually a “can’t miss” event on its own. For example, the previous ScyllaDB University LIVE featured an all-star panel with Guy Shtub (Head of Training) hosting Avi Kivity (CTO and co-founder), Dor Laor (CEO and co-founder), and Tzach Livyatan (VP of Product).
They responded to attendees’ questions about topics like:
- What was the key pain point that led to the creation of ScyllaDB, the fastest NoSQL Database
- What’s on ScyllaDB’s product roadmap
- The variety of deployment options for ScyllaDB Cloud (database-as-a-service)
- Strategies for architecting clusters for predictable latencies and lower costs
- How ScyllaDB compares to other databases known for speed and scalability
Although ScyllaDB LIVE sessions are not available on-demand, we made an exception here so we could give you a taste of what ScyllaDB LIVE involves – beyond two parallel tracks of strategy-packed technical sessions.
Here are a few highlights from the panel…
What’s next for ScyllaDB’s Raft implementation?
Tzach: We are using a Raft consensus algorithm to bring more consistency guarantees to the database. In [ScyllaDB] 5.0, we bring consistent schema updates to the database. You can do actions like create key space, create table, alter table, etc. in a consistent way.
Those of you who might have stretched ScyllaDB in the past by trying to do a lot of schema updates from different clients at the same time – which I’m sure is a minority of the population – might have hit problems with schema consistency, where the schema is out of sync in different nodes (this can also can be the result of network failures). With consistent schema updates with Raft, it’s basically impossible. Raft guarantees that all the updates are completely serialized and applied or not applied to the entire cluster. But that’s only the first step for our Raft usage. And very soon, we will offer consistent topology changes with Raft. I’ll let Avi answer about even more advanced usage of Raft.
Avi: Raft will have a place both in the control plane and in the data plane. We started with a control plane, and the initial step is to just do everything that’s done with eventual consistency, but make it safe, and then start to expand from there. We leverage the better consistency of Raft to allow us to do things like expand more than one node at a time. And move to a tablet organization where it’s easier to move data quickly among nodes. Right now, adding a node is an operation that takes hours and requires planning. But, in the modern cloud, one expects that it takes less time and can be done very quickly. And the enhanced control plane will allow us to do that.
The other direction, which is in the planning stage, is to use Raft for the data plane. So in addition to eventual consistency, we will also have a Raft-based consistency model, which will trade off some of the availability for better consistency. Basically, every operation will be like a Lightweight Transaction. It will offer the same guarantees as a Lightweight Transaction, but with the performance of normal reads and writes. And on that, we will build more features and will generally increase the number of things that you can do with ScyllaDB. It will come with a tradeoff. But, you will also always have both models to choose from. You can pick the one that suits your needs.
When should I use CQL vs ScyllaDB’s Open Source DynamoDB API (Alternator)?
Tzach: I will answer from my point of view, and maybe others can comment on it. If you’re already using DynamoDB, I would recommend starting with this API just because it’s easier. Your application is already written, and it’s easier to get started. And vice versa. If you’re already using Apache Cassandra or one of the other databases out there using CQL, it’s very easy to migrate to ScyllaDB using the same exact application – everything is compatible. You can enjoy the benefits and the cost savings that come with ScyllaDB without much effort. If you don’t have anything and you want to start from scratch, I’d probably go with CQL because it has richer semantics in many points.
Dor: It’s richer and it has better performance because of prepared statements. Definitely, if you’re on a greenfield application, start with CQL. If you’re coming with an existing application, start with the protocol that you already use.
Between Cassandra, ScyllaDB, and Redis, what are the pros and cons of each – and are there cases where you would not recommend using ScyllaDB?
Tzach: To be honest, between the alternatives you mentioned, I would choose ScyllaDB. Of course, I’m a little biased, but the other databases in this case do not have a competitive advantage. ScyllaDB works at the speed of Redis, but has a lot of Cassandra features, and features beyond Cassandra. I would say that ScyllaDB is built for big data, high availability, and speed. If your use case is very, very small – you have just a few gigabytes of data or something like that – and you don’t really need high availability, then maybe you can use something smaller and simpler. But if you do need high availability and you plan to grow to big data, ScyllaDB is the right choice for you.
Avi: I think that Redis does offer a richer set of verbs, of APIs, so you can do more things with the data. But the tradeoff is that you have to keep the data in memory. So, if your data is small enough that keeping it in memory isn’t cost prohibitive, then Redis is a fine choice. Also, if it’s a cache-style use case where you can always recover the data from different places, Redis has a more relaxed durability model – although maybe that’s fine, as well. It depends on your durability model. If data can fit in memory, or if you have an unlimited budget, then Redis can work well. If you have multiple terabytes of data, then ScyllaDB will be more economical. And comparing with Cassandra, it’s more or less equivalent in terms of features, and ScyllaDB offers better density and better performance. So, I don’t see a reason to choose Cassandra.
Dor: ScyllaDB provides performance advantages vs Cassandra. But beyond performance, there’s also functionality like CDC and materialized views, which isn’t supported by Cassandra. And we’re now proceeding towards Raft. And also in terms of operational aspects, it’s much easier to operate ScyllaDB than Cassandra. Redis is primarily cache. If you just need a cache, maybe Redis is sufficient. It’s still complicated to run if you have a scalable deployment and ScyllaDB has lots of availability advantages. So probably, in many cases, ScyllaDB is a better choice than Redis unless you need the very specific APIs that Redis has for caching.
Get Your Burning NoSQL Questions Answered at ScyllaDB LIVE, December 1
The upcoming session of ScyllaDB LIVE will feature a brand new roundtable, as well as numerous other opportunities to get your ScyllaDB questions answered. It’s a great combo of professional development, fun, and connecting with your peers.
Sessions are live, and there will not be an on-demand equivalent, so mark your calendars to attend the live event.
We’ll start by welcoming you on the Main stage. Guy Shtub, Head of Training, will give a quick overview of the different sessions and what you can expect. Then, also on the Main stage, Tzach, our VP of Product, will talk about our latest release, ScyllaDB 5.1, new features, changes, and what’s on the roadmap. Next, we’ll offer sessions across two parallel tracks.
|Essentials Track||Advanced Track|
|Getting Started with ScyllaDB
Learn how ScyllaDB works, assess if it’s a good fit for your team’s use case, and see what’s involved in spinning up your first ScyllaDB cluster and running some basic queries.
|Advanced Topics in ScyllaDB
Learn how to increase performance and efficiency by mastering the usage of collections, user-defined types, materialized views, secondary indexes, prepared statements, paging, retries, and more.
This session is a “bootcamp” for getting started with ScyllaDB. It covers best practices for NoSQL data modeling, selecting the right compaction strategy for your workload type, selecting and working with drivers, and more.
|Interactive Troubleshooting in ScyllaDB
This session shares the process that our experts use to diagnose and resolve emerging database issues. It will include (anonymized) real-world examples based on what we have seen working with ScyllaDB users.
|Build Your First ScyllaDB-Powered App
This session is a hands-on demonstration of how to create a full-stack app powered by ScyllaDB Cloud.
|Leveraging ScyllaDB’s DynamoDB API
This session is a hands-on demonstration of how to build a DynamoDB-compatible application that can be deployed wherever you want: on-premises or on any public cloud. It also covers an example of data migration and the different ways of performing it.
The NoSQL roundtable will follow the training sessions, with special guests ready to answer your most pressing questions about NoSQL, ScyllaDB, and distributed data systems.
You’ll also be invited to complete quizzes, take our hands-on labs and receive certificates of completion (and exclusive ScyllaDB swag!).
Hope to see you there!