For example, we know that we're not going to have any single point of failure, so one of the great things about Apache Cassandra is that it's a peer to peer technology so there is no master-slave, there's no failover, there is no leader election and there is none of this funny business that we really have to worry about anymore.
Out of the box with the open-source, we can do multi–DC, so when we're talking of high availability we want to be able to withstand the failure of an entire data center. Apache Cassandra can do that, you absolutely are not going to get that out of a relational database. We also want to deploy everything in commodity hardware - we talked in our previous posts about how expensive it is to scale things up vertically. With Apache Cassandra, you're going to put it on cheap hardware, and you're just going to use a bunch of it. It's easy to manage and speaking of management, it's extremely easy to manage operationally, you can take the same three-man team and have them manage a 3 node cluster or 30 node clusters or 100 node clusters. We even have put this into production with that size team, and it works!!!
One thing to keep in mind is it is not a drop-in replacement for a relational database, so you're not going to take the same data model and just throw it in Apache Cassandra and hope it works. For you are going to have to design your application around Cassandra's data modeling rules, but the net result is an application that will never go down.
or machines could actually be physical computers, all participating in a cluster all equal, and each node owns a range of hashes, so like a bucket of hashes and when you define a data model in Apache Cassandra, we won't be talking too much about SQL in this topic, but when you define a data model in Cassandra when you create a table, one of the things that you specify is a primary key and part of that primary key is something called the partition key.
The partitions key is what's used when you insert data into Cassandra the value of that partition key is run through a consistent hashing function and depending on the output, we can figure out which bucket or which range of hashes that value fits into and thus which node we need to go talk to uh to distribute the data around the cluster.
The other cool thing about Apache Cassandra is that data is replicated to multiple servers and that all of those servers, all of them are equal so like we mentioned when we were just talking on the previous topic, there's none of this master-slave, there's no zookeeper, there are no config servers. All nodes are equal, any node in the cluster can service any given read or write request for the cluster.
One of the things that are important to understand when looking at a database is how the cap theorem works so the cap theorem says that during a network partition, which means when computers can't talk to each other, either between data centers are on a single network that you can either choose consistency (actually you can't get consistency) or you can get high availability, so really what happens here is if two machines can't talk, and you do a right to know, and you have to be completely consistent, they can't talk to each other, the system is going to appear as if it's down so if we give up consistency, that means we can be highly available. That's what Apache Cassandra decides: it selects to be highly available in a network partition as opposed to being down and a lot of applications, this is way better than downtime.
We need to know is from the data center to data center, let's say we were to take three data centers around the world, maybe one in the U.S. one in Europe, one in Asia it's completely impractical to try to be consistent across data centers. We want to asynchronously replicate our data from one DC to another because it just takes way too long for data to travel from the USA to Asia were limited by the speed of light here this is something that we are never going to get around it's just not gonna happen. That's why we decide availability, and that's how consistency is affected.
Now let’s talk about some of the dials that Apache Cassandra puts into your hands as a developer to kind of control this idea of fault tolerance, so we mentioned the cap theorem earlier, this idea of being possibly more consistent or being more available it's kind of a sliding scale and Cassandra doesn't impose one model on you. You get a couple of dials that you get to turn to configure this, this idea of being more consistent or more available. So the first one we want to talk about is replication so replication, usually, this is called replication factor, it's abbreviated as our RF you'll see that a lot when you're looking at Cassandra documentation and whatnot.
A very typical replication factor for people running in production is a replication factor of three, and essentially all this means is how many copies of each piece of data should there be in your cluster? So when I do write to Apache Cassandra, you can see in this example, in the slide here, clients writing a the A note gets a copy, the B note gets a copy in the C note, there also gets a copy so three copies total for an RF=3. Data is always replicated in Cassandra, so we're gonna talk on the next slide about consistency level data is always replicated in Cassandra you set this replication factor when you configure keyspace, which in Apache Cassandra is essentially a collection of tables it's very similar to a Schema and Oracle or a database in MySQL or Microsoft Sequel Server.
This replication happens asynchronously and if a machine is down while this replication is supposed to go on, whatever knows you happen to be talking to is going to save what's called a hint and Apache Cassandra uses something called hinted handoffs to be able to replay when that node comes back up and rejoins the cluster to be able to replay all the rights that that note that was down, missed. The other dial that Cassandra gives you as a developer is something called consistency level, so you get to set this on any given read or write a request that you do as a developer from your application, talking to Cassandra. So I'm going to show you an example of two of the most popular consistency levels with the hope that that will kind of illustrate exactly what consistency level means.
A consistency level means how many replicas do I need to hear when I do read or write before that read or that right is considered successful. So if I'm doing a read, how many replicas do I need to hear from before Apache Cassandra gives the data back to the client? If I'm doing a right, how many replicas need to say, yep, we got your data, we've written out to disk before Cassandra replies to the client and says, “yep – got your data” so the two most popular consistency levels are consistency level of one, which like the name is sort of implies, just means one replica. So you can see that first example, their client is writing a to the cluster, the A note gets its copy, and since we're writing at a consistency level of one, we can acknowledge right back to the client immediately – “we got the data”. The dash lines on that diagram there are to indicate to you that just because you write with the consistency level of one, It doesn't mean that Apache Cassandra is not going to honor your replication factors still. Now, the other most popular consistency level that people use a lot is a Quorum.
Quorum, if you've never heard the term before, essentially means a majority of replicas so, in the case of a replication factor of 3, this is 2 out of 3 for 51% or greater. So in this example, again we got a client writing A, and you can see the A note, gets a copy, the B note gets a copy in response and at that point, once we've got two out of the three replicas that have acknowledged, we can acknowledge back to the client – “we've got your data” now again, dashed line indicates that you know, we're still gonna on your replication factor, we're just not waiting on that extra node to reply before we acknowledge back to the client.
You might say – “Well, why would I pick one consistency level versus another? You know, what kind of uh impact is it going to have?” — One pretty obvious one if you think about it is how fast you can read and write data is definitely going to be impacted by what consistency level use so if I'm using a lower consistency level, like say 1, if I'm only waiting on a single server, I'm gonna be able to read and write data really really quickly whereas if I'm using a higher consistency level going to be much slower to read and write data.
The other thing that you kind of has to keep in mind with consistency, level, is this is also going to impact your availability. If I choose a higher consistency level where I have to hear from more nodes where more nodes have to be online to be able to acknowledge reads and writes, then I'm going to be less available I'm going to be less tolerant 2 nodes going down whereas if I choose a lower consistency level, like 1, I'm going to be much more highly available I'm going to be able to withstand in this example here, within our 3, I'm going to be able to withstand 2 nodes going down and still be able to do reads and writes in my cluster and Cassandra lets you pick this for every query you do. So it's not going to impose one model, you as a developer get to decide which consistency level is appropriate for which parts of your application.
One of the great things about Apache Cassandra because we get asynchronous replication is that it's really easy to do multiple data centers, so when we do a right to a single data center we can specify our consistency level maybe we say 1 a Quorum.
If we're doing multiple data centers, we're gonna say local one or local Quorum – now, when that happens, you get your right and it happens in your local data center, and then it returns to the client, and then let's say you had five data centers the information that you wrote to your first data center is going to be asynchronously replicated to the other data centers around the world. This is very, very powerful this is how you can get super, super high availability even when an entire data center goes down, so you can specify the replication factor perky space so you can have one keyspace that has five replicas, one that has 3/1 that has one it's completely up to you and completely configurable. It's important to understand that a data center can be logical or physical, one of the things that's great about Apache Cassandra is that you can run it with a tool like Spark. If you're doing that, you may want to have one data center, which is your LOTP, you're serving your fast reads to application and then one data center virtually, that's serving your whole app queries and then doing that you can make sure that your whole app queries don't impact LOTP stuff.
If you liked our article check others: