Databases Reference
In-Depth Information
Though more adept at dealing with very large datasets, these alternative models tend
to be less expressive than the relational one (with the exception of the graph model,
which is actually
more
expressive).
But volume isn't the only problem modern web-facing systems have to deal with. Besides
being big, today's data often changes very rapidly.
Velocity
is the rate at which data
changes over time.
Velocity is rarely a static metric: internal and external changes to a system and the
context in which it is employed can have considerable impact on velocity. Coupled with
high volume, variable velocity requires data stores to not only handle sustained levels
of high write loads, but also deal with peaks.
There is another aspect to velocity, which is the rate at which the structure of the data
changes. In other words, in addition to the value of specific properties changing, the
overall structure of the elements hosting those properties can change as well. This com‐
monly occurs for two reasons. The first is fast-moving business dynamics: as the busi‐
ness changes, so do its data needs. The second is that data acquisition is often an ex‐
perimental affair: some properties are captured “just in case,” others are introduced at
a later point based on changed needs; the ones that prove valuable to the business stay
around, others fall by the wayside. Both these forms of velocity are problematic in the
relational world, where high write loads translate into a high processing cost, and high
schema volatility has a high operational cost.
Although commentators have later added other useful requirements to the original
quest for scale, the final key aspect is the realization that data is far more varied than
the data we've dealt with in the relational world. For existential proof, think of all those
nulls in our tables and the null checks in our code. This has driven out the final widely
agreed upon facet,
variety
, which we define as the degree to which data is regularly or
irregularly structured, dense or sparse, connected or disconnected.
ACID versus BASE
When we first encounter NOSQL we often consider it in the context of what many of
us are already familiar with: relational databases. Although we know the data and query
model will be different (after all, there's no SQL!), the consistency models used by
NOSQL stores can also be quite different from those employed by relational databases.
Many NOSQL databases use different consistency models to support the differences in
volume, velocity, and variety of data discussed earlier.
