Database Reference
In-Depth Information
Fully denormalizing the home timeline
The partially denormalized structure we built using the home_status_update_ids
table certainly improves read-time performance, but we're still not at the sweet spot of
querying exactly one partition to display the home timeline. In order to do this, we'll need
to take the denormalization one step further.
Instead of storing references to status updates in the home timeline, we'll store actual cop-
ies of the status updates. Each user's timeline will contain its own copy of the status up-
dates of all the users they follow. We create the following table:
CREATE TABLE "home_status_updates" (
"timeline_username" text,
"status_update_id" timeuuid,
"status_update_username" text,
"body" text,
PRIMARY KEY ("timeline_username", "status_update_id")
) WITH CLUSTERING ORDER BY ("status_update_id" DESC);
This table looks very much like the home_status_update_ids table, except it con-
tains an additional body column. By adding body , we now have a table that will hold a
copy of all the data in a given status update; if user_status_updates had ten
columns, then we would put all ten columns on home_status_updates too, along
with a partition key for the user who owns the timeline.
Search WWH ::




Custom Search