Database Reference
In-Depth Information
They also work well when the query pattern is such that pulling the
document into the working set essentially “warms” it up, providing faster
access for subsequent queries.
Distributed Hash Table Stores
Stores like Cassandra, Voldemort, BigTable, and DynamoDB are a bit of
a mix between a relational database and a key-value store. Like key-value
stores, they work best when the patterns of aggregation are well known
so that they can be denormalized by the processing infrastructure. The
batch update feature of Cassandra exists essentially to encourage this sort of
multitable update.
Unlike key-value stores, they usually provide efficient range or set querying.
They also usually support secondary indexing to improve query
performance. This can be arranged in key-value stores like Redis using
features like sorted sets, but it becomes inconvenient when the queries get
complicated.
Unlike relational databases, these types of stores usually do not support
ad
hoc
aggregation very well. They do not typically support
GROUP BY
and
SUM
operations, requiring client-side aggregation. This makes them a poor
choice for more exploratory data environments unless their integration with
map-reduce environments will be used to perform the aggregation.
In-Memory Grids
These tend to work well in instances where distributed hash table or
key-value stores work well. Due to the fact that all data is held in-memory,
accessing and updating the data is usually very fast. However, it also makes
them more expensive than disk-based distributed hash tables (DHTs). Most
provide some querying and indexing capabilities, making them similar to
DHT approaches.
They also work well when the storage is tightly coupled to the application.
Forexample, alegacyapplication thatassumesascale-uparchitecture being
adapted to a scale-out architecture that can be fed from a real-time
streaming system.
