Basic Concepts and Intro to Architecture – Part 2

The way that it works is that each
node is responsible for a range of tokens.
This is a bit of a simplification.
But in this example, we can see that, for example,
the first node is responsible for the range of 1 to 400
and so on.
And according to the partitioner, Scylla knows
which node is responsible for the data.
And by the way, I’m showing you how this works under the hood.
So this is what the system does,
as a user that performs the query
you don’t have to worry about that or do anything.
But it is important to understand that
this is how ScyllaDB works under the hood.
Okay.
So I mentioned data is replicated
and this is determined according to a setting called
the “Replication Factor”, abbreviated to it also as RF.
And the replication factor is the number of nodes
where data are replicated.
Okay.
This is done automatically and it’s configured per keyspace.
So a keyspace is
an aggregate that has multiple tables
and all the tables in the keyspace are going to inherit
the replication factor.
Here in the example you see
a command to create the keyspace that has a replication factor
of three.
Now if we have a replication factor of three,
it means that each
each one sorry,
each piece of data is replicated
three times to three different nodes.
So we’re going to hold three copies of each piece of data
if the replication factor is three.
And that means that even if one of the replica nodes
goes down, we can still serve requests.
Let me stop for a second and see
if there are any questions in the chat window.
I’m not going to be able to answer all of them.
So there’s one question.
If one of the three nodes
goes down, will the database still be available?
So that depends.
If we have a replication factor of three
and one of the nodes goes down,
we can still access the data because
we have two other replicas that hold the copy of the data.
So the question is.
Sorry.. So the answer is that yes,
the data will still be available.
Another question is: can the partition
include secondary keys in addition to the primary key?
So the terms here are a bit different.
A primary key
includes the partition key and the clustering key.
And I’ll talk about that just a bit in this talk,
but it’s covered quite extensively in the next talk.
So if that’s interesting for you,
stick around for the next talk and the essentials track
and I will talk about the primary key,
partition key and clustering key quite a bit.
So I want to move forward.
I have quite a lot of material.
You can save your questions for the Q&A or for the
expert panel.
Great.
So I talked about the replication factor.
Another important concept is the consistency level or CL.
CL is the number of nodes that must acknowledge a read
or a write request.
Some example of possible values are one.
So just one node needs to acknowledge the request.
Quorum means that quorum of the nodes
needs to, or All meaning all replica nodes
need to acknowledge the read or the write request.
And this is something that’s tunable.
So the consistency level can be set per operation.
Okay.
So maybe in your specific application you have a use case
where writes don’t need to have a very high consistency.
You can set the consistency level to one,
but maybe the reads, they require a higher consistency.
So in that case, you might want to set the consistency level
to be higher.
And I would show an example of this in just a bit.
Datacenters, so ScyllaDB is topology
aware, it’s built to work with multiple data centers.
It’s also rack aware.
And there are a few reasons to use
multiple data centers and to be topology aware
in these examples, we’re having a cluster that’s
basically using two data centers,
for example, one in the U.S.
and one in Asia.
And it would make sense to serve users
that are located in the U.S.
to serve their queries from the U.S.
data center just because it’s closer.
And for performance reasons, it’s going to be quicker
to serve those requests.
Another reason to use multiple
data centers would be, again, for high availability.
So even if a specific rack or even an entire data center
goes down, say, there is a disaster in the U.S.
datacenter, our system would still be up and running
and we would be serving requests from the Asia datacenter. Once
the U.S.
datacenter recovered and goes back up, the Asia datacenter
would propagate the data to the data center that was down.
That is called entropy and
anti entropy mechanisms dealing with repair.
And if you’re interested in that, then Tzach
is going to cover that.
In his talk about ScyllaDB power users,
and that’s the third talk in the advanced struct.
So if you’re interested in anti entropy mechanisms, repair
tombstones and more advanced topics, check out that talk.
Maybe just another benefit of using data centers
is for compliance reasons.
So maybe we have a compliance demand
that data
for users in a specific geographical location, say
in the US,
all their data stays within the U.S.
so then we can keep their data in the U.S.
datacenter and
comply to those requirements.