Databases Reference
In-Depth Information
It might seem odd to focus on rows when the data model is ostensibly columnar, but
individual level rows really are important, because they provide the nested hashmap
structure into which we decompose our data. In
Figure A-5
we show how we might map
a recording artist and his albums into a super column family structure—logically, it's
really nothing more than maps of maps.
Figure A-5. Storing line-of-business data in a super column family
In a column family database, each row in the table represents a particular overarching
entity (e.g., everything about an artist). These column families are containers for related
pieces of data, such as the artist's name and discography. Within the column families
we find actual key-value data, such as album release dates and the artist's date of birth.
Helpfully, this row-oriented view can be turned through 90 degrees to arrive at a
column-oriented view. Where each row gives a complete view of one entity, the column
view naturally indexes particular aspects across the whole dataset. For example, as we
see in
Figure A-6
, by “lining up” keys we are able to find all the rows where the artist is
English. From there it's easy to extract complete artist data from each row. It's not con‐
nected data as we'd find in a graph, but it does at least provide some insight into a set
of related entities.
