 Hello everyone, today we are here to talk about Apache Cassandra Sidecar. Cassandra Sidecar is a management process for managing Cassandra database. Briefly about us, I am Sarena Krishna Kumar. I've been working at Apple as a software engineer and for the last four years I've worked on various projects related to Cassandra Sidecar. Yeah and my name is Francisco Guerrero. I've also been working with Sarena for the past two years in the Cassandra Sidecar project. Today we will go over what is Cassandra Sidecar and why we need a Sidecar process for Cassandra database. What is its architecture, some of Sidecar's use cases and how developers and users can get started with the project. Finally we will conclude our talk with a summary. What is Cassandra Sidecar? Cassandra Sidecar is a control plane that has been introduced for managing the Cassandra database. It is a separate JVN process that runs alongside the cluster. To run Cassandra out of the box with zero configuration we need a control plane that provides essential functionality hence authors of CEP-1 proposed adding a Sidecar into the Cassandra ecosystem. And with the control plane introduction operators can now directly interact with and administer the database through HDP APIs. They do not learn any new tool or programming languages for operating the database. Sidecar also passes the curl test. We have scale in mind while building Sidecar. It can handle queries at scale and the architecture of Sidecar is pluggable and extensible. It can be adapted to run and support Cassandra clusters of various Cassandra versions. We will go over the architecture in detail in coming slides. Why do we need a Sidecar process? Cassandra clusters are generally hard to operate. We need various automation tools for maintaining the cluster. For example, we need maintenance tools for restarting clusters and we need migration tools for moving data from one cluster to another. And apart from operating we also need execution tools for executing commands at bulk in Cassandra. Hence we need a Sidecar process that combines all of these maintenance operations and execution into one process and the Sidecar can provide these functionalities through REST APIs. And with REST APIs the interactions will be easy and both straightforward. Some of the functionality that has already been added to Sidecar are running error checks and getting a view of the cluster, getting cluster settings, capturing data, capturing a snapshot of the data and streaming data to and from Cassandra. So a control plane solution, for example, in a control plane solution will have all these functionalities in one place and it is, it will be a common control plane that is introduced in open source. In a previous talk by Dinesh Chhurshi on Cassandra analytics, he went over how read write path of Cassandra is very expensive and how it has various steps included. Cassandra Sidecar will also allow us to bridge gaps when directly talking to Cassandra is expensive. Sidecar can directly access the data directories of Cassandra and hence bulk reads and writes can be easier with Sidecar. So why the effort in open source? The main motivation behind building a Sidecar solution in open source is that because of the complexity of operating Cassandra, everybody will have their own Sidecar solution in their environment. And this effort was more to consolidate all that and have a control plane in open source. Now I will hand it over to my teammate to talk about the architecture in detail. Yeah, thank you, Seren. Yeah, let's go over the architecture and we're going to deep dive into some of the details of Sidecar. So Sidecar is built on top of Vertex. Vertex itself is a toolkit to build reactive applications and we wanted to leverage this asynchronous nature of and reactive of Vertex because this allows us to scale up as the workloads grow. It also offers resiliency when we encounter failures. As it stands today, Sidecar is a stateless process. Vertex itself is built on top of NETI. And in a traditional application server, we have something like this. We get a request and a single thread is going to be handling the request during the life cycle of the request. That means if we do some database access or if we go to the file system or we talk to S3 or we have some blocking IO operation that is very expensive, that thread is going to be wasting CPU time. So we can see that in this slide how we have multiple threads and in the red we have these blocking IO operations. So these traditional application servers are well suited for medium workloads and as your workloads grow, you need to scale horizontally. You need to add more resources, more boxes to be able to handle more requests. So for that reason, we decided to use the asynchronous programming model that we get from Vertex and that allows us to reuse resources more effectively. We don't need that many threads to process requests when we have a blocking IO operation. We just move on to the next task and then we can come back to the initial task when that blocking operation completes. So Vertex multiplex is concurrent workloads using the event loop. And that allows us to use the hardware more effectively. We can handle more requests and that's what we need for a project like Cassandra because we're dealing with massive amount of data. Let's take a look at the components in Psycar. So we have a server, we have a Java-based client and we recently introduced the NJVM distributed testing. In the server, we have route handler. So when we get our arrest requests, we're going to be routing those requests to the specific handler. We have adapters for different Cassandra versions and we have periodic tasks. For example, we do periodic health checks to the database. The Java client was recently introduced as well and it has a lot of features. It's a feature-rich client that allows us to do retries. We can have retry policies and exponential back off and we handle different status codes from the server. And the NJVM distributed testing was a massive undertaking to bring it over to the Psycar project. This allows us to build a more robust project and we have more confidence of the project and we know that the project that we are putting out there is well covered in terms of testing. That was a big effort that we did to bring it over. Looking at the server, the server can manage the Psycar server, can manage one or more Cassandra instances and we perform health checks on every of the instances that we manage and then we can adapt to the different versions of Cassandra. So we can see that on the left we have the Psycar process and on the right we have a Cassandra ring so we can handle one or more instances. We have these adapters so let's say we want to do an SS table upload. We have a handler for that. We want to do an import of data or if we want to get the schema of a key space we have all these adapters and we have all these handlers and we have adapters and these adapters are version specific for Cassandra so and this means that they are tied to a specific instance of Cassandra. So if we run in a mixed mode we would have an adapter for this instance which is running Cassandra for all and we would have different adapters based on how many instances we are managing and the way we talk to Cassandra is via JMX and CQL and the adapters give us the interfaces to talk to Cassandra so we have interfaces for the storage and for storage or for cluster operations. We have all these interfaces that are abstracted for different versions of Cassandra. So let's say we want to run an SS table import. We get a REST request for instance one. This request is going to get routed to the correct handler so we would use this import handler and then we need to get a reference for the Cassandra adapter and that is going to be specific for that version so we know that we we're going to be running the JMX command to do the imports. Now let's say we want to do an we want to upgrade to Cassandra 5. So what Sidecar is going to do is it's going to notice that there's going to be a disconnection when we start to upgrade this node. So we no longer have the adapter and we are still going to do the health checks and when we are able to establish the CQL connection we can bring a new adapter and this adapter is going to be for Cassandra 5.0 and because we have these interfaces that are transparent to the handlers we are going to still going to be able to serve requests so we established the JMX connection and that's how adapters are created and managed per Cassandra instance based on the health checks and then I'll hand it back to Saranya she's going to talk about use cases. Thanks Francisco. Now we will go over the use some of the use cases of Sidecar. Sidecar enables faster analytics. Through CEP 28 analytics project was introduced in open source for bulk reading and writing data to and from Cassandra. Sidecar provides some of the key functionality needed for analytics project. It provides REST APIs that can stream data directly from data directories using zero copy streaming technique and it does that without loading data in memory. It also has REST APIs for importing SS tables into the data directories after performing validations of data. With analytics project bulk reads and writes are at least 30x faster. So what is the impact of analytics on Cassandra? Computation needs are now needed for bulk reading data out of Cassandra and now moved out of Cassandra into an isolated process that is Sidecar. Bulk reads through Sidecar have minimal impact on IO during this reads. We also have throttlers in place. Throttlers in place for both checking the bandwidth used and for checking the number of connections created to avoid overuse of CPU. During bulk writes through the analytics project is much faster than regular writes. Analytics is only one of the use cases of Sidecar. More such use cases are coming. So getting started. Developers and users can get started with the project. The project is present under Apache here and there is a read me as part of the project which will help getting started with the IDE, setting up the IDE. For experimenting you can start a local three node cluster and run Sidecar out of the box with minimal configuration change to the YAML. There is a dev module that is part of the project which allows for this local run. And we warmly welcome new contributions. Some of the areas of interest are cluster wide APIs and adding authentication and authorization to Sidecar process because securing the process is important. And you can also add schedule tasks to the management process. We track open issues through Apache Jira and interested people can turn the dev mailing list where we talk about features bugs or in general chat with the community. There is also an ASF Slack channel. Now let's go over the summary of our talk. In our talk today we saw what is the sidecar and how a sidecar process access and interface between operators and the database. And it provides some of the key functionality needed for maintaining the database and it does that through rest APIs, which is easy to interact with. We also saw in detail about Sidecar architecture. It is a pluggable and extensible architecture that can be adapted to support various Cassandra versions. We saw some of its use cases. Thank you for taking an interest in our talk. We can move over to Q&A. Not yet but there are efforts to bring that over to Sidecar. So some coordination to be able to have some sort of leader election for different purposes. So that's that's part of the CEP. One of the things that we wanted or Sidecar wants to address is this cluster wide API. So you just need to talk to a single Sidecar and this Sidecar is going to do the coordination. So that's part of the CEP right now. But yeah, that's something that we definitely want in Sidecar. Currently, it's manually written because we wanted some customized features. But there were efforts to have it automatically generated, which I think it would be better if you wouldn't be dying to like Java. You could have clients for other technologies. So the question is, is the proposal for Sidecar to talk to different Sidecars or to multiple Cassandra processes? Okay. No, I think the proposal is for Sidecar to be able to talk to other Sidecars. So there was like some coordination. We've seen yeah, multiple Sidecars and everybody's doing things differently. So ideally, we want to consolidate all those efforts into a single project. And that's why we came here to talk to you to be able to, yeah, we want to get people together and make them learn more about the project. And hopefully, we have like a single community driven Sidecar, which everybody's going to benefit from a single project. So Sidecar can talk to the instances it does through JMX and secure like we covered, but for having the advantage of it being able to make communication faster, like for example, directly streaming from data directories, we needed to be able to read the file system. Yeah. So for these bulk operations that we introduced, yeah, we need file system access. Yeah, you can do a data frame read and then write to a different cluster. And the advantage is that if you have clusters with different topologies, Spark is going to repartition the data such that you read from the original topology and then you repartition the data for the target topology of the new cluster. Yeah, thank you. Thank you very much.