Database Reference
In-Depth Information
Again, the timer shows that you should close the topic and design your tables.
Nothing teaches as well as practice. Let me illustrate this with a story. The sages of
old debated for 18 months: which is more important, the study or the deed? Having
exhausted all philosophical arguments, they resorted to voting, and the school which
was more numerous won, "Study is more important, because it leads to the deed."
In our context, immediately after studying the theory of the NoSQL design, you need
to apply it in practice. Here's our answer to this problem:
Let's discuss this:
• Friendship is represented in columns:
We will have to update anyone's information at two places, that is, in the
<user_id>
and friends columns, especially if we store more information
about the users than we show in this simple sketch of the implementation.
That's all right; the columns that are stored in HBase are sorted, so finding
a particular user in the friends list is fast.
• When user A is friends with user B, how many entries will be created?
The answer is two. Friendship is mutual; thus, if user B is a friend of user
A, then user A is a friend of user B. We will write two records, one for user
A and one for user B. Again, this is fast enough. Since we are essentially
writing
<user_id>
and
<friend_id>
in the
<user_id>
row, each write goes
independently into its column. In the physical implementation of HBase,
this can be executed in parallel. The code does not need to read all the
columns for the
<user_id>
row before it updates the row—this is the
beauty of NoSQL.
• What happens when a user account is deleted?
Again, you will have to update two rows, one for user A and his/her
friend (user B), and one for user B and his/her friend (user A). The physical
implementation of the deletion in HBase is writing a tombstone marker,
which leads to no row lock and is fast.
