Learn what happens in terms of storage when reading/writing data to ScyllaDB, what is Compaction and why it is necessary.
And with that, let me
to demo that quickly. I’ll jump to the terminal,
and I hope the font is large enough for you to see.
So in this said quick demo,. I actually have
everything running on my laptop using “Docker”.
So I run free Docker instance of Scylla, created the cluster
and let me now…, the “nodetool
status” by the way, is a quick tool
to see the status of the cluster.
You see here that they had three nodes, so now I’m
using a tool called “cqlsh” to connect to the cluster
and let, let me start actually creating something with it.
So the first thing. I’m going to do
is I’m going to create the keyspace.
A keyspace for those of you that are not familiar
is a collection of “table” in the keyspace
you define the replication factor of the cluster.
So following the
slides, I’m going to use
replication factor of three
and I created the keyspace.
By the way, unlike in the deck,. I had the cluster
with five nodes, here
I only have three nodes because my laptop is pretty weak
and five Docker is
is a little bit too much for it already.
Okay, so I created a keyspace.
Now let me create, use the keyspace.
Let me create a “table”.
Okay.
For those of you that saw Guy presentation earlier about the
how to use case, I’m
following the same example.. So I have a table here
with four columns – “pet_chip_id”, “owner”
that you can ignore for this example, “time
timestamp” and “heart rate”.
The primary key is
composed of “pet_chip_id” and “time”
where “pet_chip_id” is the partition key
and “time” is a clustering key, together the “pet_chip_id”
and the “time” are the primary key. Okay,
so I hope everything’s understood so far.
Let me try to insert the value into the cluster.
So this is a syntax.
Maybe it’s a little bit hard to read,
but I’m inserting into a table, specify
the column and put some values and now just for the demo,
let me do a quick select, there.
Okay.
The information is here
and everything is okay, but I didn’t show anything
about consistency, so let me do the following first,
when I’m working like that, we
“cqlsh” by default, which consistency I’m using?
Anyone can guess what is the default consistency?
Yeah.
Okay. Good guess by John.
It is one
that’s the default and “cqlsh” and I can actually see
the consistency from just writing consistency.
I could see the consistency level is one.
Let me for this demo activate the feature called tracing.
So I’m doing tracing on and let me do
the same insert command again.
The screen will be filled with information.
So let me
try to zoom down
the font a little bit
just so we can see it in a format of a table.
I know it’s going to be hard to read, but
bear with me.
I hope you can read something.
Okay, so what we are seeing here,
the trace command first execute the command, then dump
the trace to the screen.. This is a useful debugging tool
because it allows me to see the flow of the information
between the nodes.
I know that you cannot…
It’s a very hard to read everything,
but just to show you a few interesting data points.
First, the source column is which,
you can see which node actually execute the command.
You can see in this case that the node that ends with two
“172.17.0.2” it’s the Docker container or Scylla node
acting both as a coordinator and as a replica in this case.
And so it’s doing most of the work.
It did send messages
to the replica to where
the nodes that end with three and four.
They processed the message as well.
And it’s by the way, it’s called mutation.
Sending a mutation.
Mutation can be
update, insert or delete.
They’re all the same.
What I want you to see,
I don’t know if you can read it, but at some point
the coordinator node reported “done processing –
preparing the result”, this is the point in time
when the coordinator decides it can send back the response
to the client.
The success response in this case.
Note that is doing that
even before it got response from the other nodes. Why?
Because in consistency level of one at the coordinator,
it can be satisfied with response from one replica.
This coordinator is the replica himself.
So it’s processing the information, persists
it and can send it back to the client.
Now let me
set the consistency of
“quorum” and let’s try the same insert again.
Again, the screen is full with information,
which is a little bit hard to read,
but if you look carefully
and I’m just looking at the “done processing”, “done
processing” here is done later only when it got response from
the node that end with “3” and if I’m
doing the consistency of “all”
and running the same command,
the “done
processing” will be done only after all the nodes
send the response back. Now, just to complete
the picture of this demo, what I’m going to do,
let me quickly kill one of the nodes.
So let me be aggressive.
What I’m going to do.
I run “docker stop”,
one of the instances, “some-scylla3”
is just the name of the docker instance.
Let me run the docker status command again.
So I’m running the nodetool status again.
You can see that the one of the node is down.
Let me connect with the “cqlsh”
again.
Sorry.
Oh, it’s not “nodetool cqlsh”,
just “cqlsh” Hey,
and now let me repeat
the same insert…
will it work when I click enter right now?
we could guess. Yes.
Someone wants to guess No.
So it actually will work.
Because every time. I open a new instance of “cqlsh”
the consistency level is going back to the default.
But just to validate it.
But we write the consistency.
Consistency is one.
So if I’m doing an insert it will work.
Even though one of the nodes is down.
But if I’m writing
consistency of “all”, it will fail as expected.
