This brings us to
service level options and their relation
to those definitions or those workload characteristics.
So service level is a type of session
specific configuration that defines
some properties for the workload.
At Scylla, it is
determined by the logged in user
or role, as we call it, and all of its hierarchy.
So actually like the session properties can be composed
from the hierarchy of roles.
It also allows for session tweaking on the administrative
level as opposed to the client application level.
So if, for example, you find out that the timeout you chose is
too low or the database cannot deliver it,
you can just increase it, on by CQL
and then you don’t need to even touch or restart the
client application sometimes.
So what are our service level options?
We have, first and foremost the workload type.
It’s one of interactive or batch, OLAP or OLTP,
and we have the timeout.
So this is, this will be the default timeout for the session.
I say default because Scylla actually have
three different points where you can define the timeout
for queries.. First of all, we have
a static configuration in scylla.yaml and this will be
the effective timeout where no other timeout is given.
By the way, service level
doesn’t have to define
all of the properties,
so you can still have a situation where you do have
service level
or you did define some of the properties for the session,
but you didn’t define timeout.. And then what it will take
will be the static configuration.
It also has a “using timeout”
syntax part so you can actually run individual queries
using different timeout than the session default.
Of course that this will
restrict the administrative level of management
because whenever you need to change the timeout,
you will need to change the client application configuration
or the configuration
or the code.. It depends on the client application.
So the session timeout is somewhere in between.
It will take, it will override the static configuration,
but it will, it will take
if you use the “using timeout” syntax in the CQL.
Workflow type effect.
So workflow type only exist as a session parameter.
You cannot execute it via CQL and give each query its own
workflow type.. It’s kind of a hint for Scylla
about how to deal with an overload.
So things normally break down for any database
when it’s underload because then timeouts accumulate
and we can even
get to a situation which is called “Live Lock”,
which means that a lot of
requests are waiting in line in order to be served.
But actually, because the line is too long
or let’s say longer
than the timeout in sense of processing time,
what will actually happen is that every new request
that is queued for serving
is doomed to timeout.
So Scylla tries to deal with it
for interactive by shedding load,
which means that if Scylla figures out
that the queue is too long for the specific workload
and we can get into a situation of “live lock”
or we spend too much time serving or too much processing
time, one serving requests that are eventually timing out,
it will shed some of the of the request and this will
effectively shorten the queue,
which means that the requests that are left in the queue
will actually get served, eventually.
For batch, we have a
higher tolerance for large queues.
By the way, batch is the default if you don’t provide
the workload type in the service level.
So we will treat the
workload type as batch.
So we have higher tolerance for large queues
because if we are slow to respond,
of course within the timeout, which is normally quite big,
we can actually it will serve us as a “natural throttling”.
And on top of that, we also have some
mechanisms in place to actually throttle some requests
if we see they are still overloading the database.
So what we are building upon is this bounded concurrency
that I mentioned before, because we know that if we will
be slow to respond, so
the request will come in slower because for every request
that is served, a new one will come in from the thread that the
generated it.
