Databases Reference
In-Depth Information
Links and Walking
The Riak key-value store allows each of its stored values to be augmented with link
metadata. Each link is one-way, pointing from one stored value to another. Riak allows
any number of these links to be
walked
(in Riak terminology), making the model some‐
what connected. However, this link walking is powered by map-reduce, which is rela‐
tively latent. Unlike a graph database, this linking is suitable only for simple graph-
structured programming rather than general graph algorithms.
There's another weak point in this scheme. Because there are no identifiers that “point”
backward (the foreign aggregate “links” are not reflexive, of course), we lose the ability
to run other interesting queries on the database. For example, with the structure shown
in
Figure 2-3
, asking the database who has bought a particular product—perhaps for
the purpose of making a recommendation based on customer profile—is an expensive
operation. If we want to answer this kind of question, we will likely end up exporting
the dataset and processing it via some external compute infrastructure, such as Hadoop,
to brute-force compute the result. Alternatively, we can retrospectively insert backward-
pointing foreign aggregate references, before then querying for the result. Either way,
the results will be latent.
It's tempting to think that aggregate stores are functionally equivalent to graph databases
with respect to connected data. But this is not the case. Aggregate stores do not maintain
consistency of connected data, nor do they support what is known as
index-free adja‐
cency
, whereby elements contain direct links to their neighbors. As a result, for con‐
nected data problems, aggregate stores must employ inherently latent methods for cre‐
ating and querying relationships outside the data model.
Let's see how some of these limitations manifest themselves.
Figure 2-4
shows a small
social network as implemented using documents in an aggregate store.
