Information Technology Reference
In-Depth Information
Key-value stores are essentially very long and presumably thin
tables (in that there are not many columns associated with each row).
The table's rows can be sorted by the key-value to simplify finding the
key during a query. Alternatively, the keys can be hashed using a hash
function that maps the key to a particular location (sometimes called
a bucket ) in the table. The representation can grow indefinitely, which
makes it good for storing large amounts of data that can be accessed
relatively quickly, as well as allows massive amounts of indexed data
values to be appended to the same key-value table, which can then be
sharded or distributed across the storage nodes. Under the right con-
ditions, the table is distributed in a way that is aligned with the way
the keys are organized, so that the hashing function that is used to
determine where any specific key exists in the table can also be used to
determine which node holds that key's bucket (i.e., the portion of the
table holding that key).
NoSQL data management environments are engineered for two key
criteria:
1. Fast accessibility, whether that means inserting data into the model
or pulling it out via some query or access method
2. Scalability for volume, so as to support the accumulation and man-
agement of massive amounts of data
The different approaches are amenable to extensibility, scalability, and
distribution, and these characteristics blend nicely with programming mod-
els (like MapReduce) with straightforward creation and execution of many
parallel processing threads. Distributing a tabular data store or a key-value
store allows many queries/accesses to be performed simultaneously, espe-
cially when the hashing of the keys maps to different data storage nodes.
Employing different data allocation strategies will allow the tables to grow
indefinitely without requiring significant rebalancing. In other words, these
data organizations are designed for high-performance computing for report-
ing and analysis.
This model will not inherently provide any kind of tradi-
tional database capabilities (such as atomicity of transactions
or consistency when multiple transactions are executed
simultaneously)—those capabilities must be provided by the
application itself.
Search WWH ::




Custom Search