Database Reference
In-Depth Information
Designing around queries
Our choice to store two representations of a single follow relationship, is a prime example
of
query-driven design
: the practice of designing table schemas to accommodate the data
access patterns of our application, rather than simply building structures to naturally repres-
ent the underlying data. In the case of follow relationships, either the
user_outbound_follows
or
user_inbound_follows
table is sufficient on its
own to store the data about follow relationships; were we using a relational database, it is
likely that we would only use one of these tables, with secondary indexes on the non-key
columns for efficient lookup. But using Cassandra, neither table is able to satisfy all of the
query needs our application will have, so query-driven design instructs us to include both
in our database.
When thinking about the best way to satisfy the data access needs of our application, it's
helpful to think of our Cassandra tables in terms of core data structure: a map of values to
collections of values. If we want to know who a given user follows, we want a map of user-
names to the collection of users they follow. This abstract representation of the ideal data
structure instructs us to build a table whose primary key is a username, and whose rows
consist of usernames of users they follow.
