A view is another table, which will take space, and that depending on your partition key can be on different nodes than the base table.
The session goes over what happens behind the scenes when MV are used.
In the write path whenever you write a new record to the base table, ScyllaDB will automatically create a record in the corresponding view.
On the read path, you should query your view directly and reads on the base table will not touch the views. So there is no implicit joining.
It also explains read before write and concurrent updates.
Transcript
this is the insert path
so the write path when you have a materialized view so again we have a base
table when you insert a record on the base table and ScyllaDB sees that there’s
a materialized view created it’s automatically going to create a record
on the materialized view so that’s the convenience you don’t need to have
your application writing to two different tables because when you write
to the base table it’s going to write to the materialized view and by the way if you
create the materialized view after you already have a base table because this
case let’s say the table is empty right but if you already have like
a million records on the base table when you create a materialized view it’s
going to populate the materialized view so this is another thing to have in mind
that if you’re creating a materialized view do it off hours you know plan ahead
because it might take a while depending on how much data do you have on the base
table and then on the read path this drives me nuts instead of reading from
the base table your application is going straight to the materialized view so it’s
one hop you just go to your materialized view you’re good the secondary
indexes are different so that’s in by the way that’s the main difference
between materialized views and indexes indexes will use materialized views
underlined but your queries are made on the base table
and with materialized views you go straight to the materialized view pretty
simple right okay so this is this is how a write happens so you’re writing to to
the base replica and then it’s going to create an update or an insert on
the materialized view right let me get there so all of that is done asynchronously
so it means that if your cluster is overloaded it might be that the base
table is updated or the record is created but the view table it’s not
because if the cluster is overloaded it’s going to prioritize base table
writes and it’s going to do the view updates later so and that’s exactly to
avoid impacting the the base table availability the consistency level is
not enforced in terms of let’s say you have consistency level quorum on a three
node cluster so you need two acts before it says that that records is recorded
right so that is just for the base table it’s not going to wait for to achieve
consistency level for the view updates so again this is to talk a little
bit about the read before write pattern that is in a materialized view
so let’s say we have this base table and this is the simplest it can get right so
it’s a partition key a clustering key in a regular column with
some value right when you create a materialized view you are making that
that value your partition key so that’s the most simple example that I can give
you so let’s say we have one record with you know 0 1 and 8 so the 8 V there it’s
going to be the partition key on the materialized view right so when I update
that value and I’m changing from 8 to 10 it means that in the materialized view the
partition key eight won’t exist anymore so I have to delete it or tombstone it
and then insert the
value 10 right why we do that it’s reading from the base table before it
tombstones and create a new value and we have a lock there so because if you’re
having concurrent updates you don’t want to you know lose your updates to the
materialized view so again that case that. I mentioned for the read before write is
because of concurrent updates and so we make sure you know concurrent updates
are handled with a lock basically when you create a materialized view it’s going
to build that materialized view if you already have data on the base table
of course it’s resilient to node restarts as I told you it’s another
table so you don’t have to you know overthink it it’s just a different table
we are going to build it for you and there are we’re mentioning too
but there are three ways to see the progress right so you can query the
system_distributed.view_build _status you can use nodetool viewbuildstatus
but I keep telling people just look at the monitoring it’s there I prefer to
look at the monitoring because you know you don’t have to to run the command
every five minutes you just put on the screen and you know, go make some coffee
