Database Reference
In-Depth Information
column. This is because the
status_update_id
column alone, being a UUID,
uniquely identifies the status update, even though it is insufficient on its own to retrieve
the status update from the database. We store
status_update_username
as data
only so that we know what partition to look in when we go to retrieve the status update.
Now, let's insert some data into our new table. To keep things moving forward, let's ignore
the status updates that have already been created; we'll just start using our new timeline
structure with new status updates.
Let's say
carol
writes a new status update. Now, along with inserting the status update
into her user timeline, we'll need to add a reference to it to all her followers' home
timelines. So, the first thing we'll need to do is check who follows her:
SELECT "follower_username"
FROM "user_inbound_follows"
WHERE "followed_username" = 'carol';
We'll find that
carol
's only follower is
alice
:
Note
While this part of the process might seem simple, we should not do it lightly. Recall that
Cassandra is optimized for write performance; because of this, we should strive to avoid
reading data during write operations whenever possible. In this case, we are performing a
very efficient read operation at write time—retrieving all the rows from a single parti-
tion—in order to write a data structure that makes other read operations far more efficient.
It's a good tradeoff.
Now we will write all of the data we need to for
carol
's new status update:
INSERT INTO "user_status_updates"
("username", "id", "body")
VALUES(
