NoSQL

From Wikipedia, the free encyclopedia

Jump to navigationJump to search
"Structured storage" redirects here. For the Microsoft technology also known as structured
storage, see COM Structured Storage.
A NoSQL (originally referring to "non SQL" or "non relational") [1] database provides a
mechanism for storage and retrieval of data that is modeled in means other than the tabular
relations used in relational databases. Such databases have existed since the late 1960s,
but did not obtain the "NoSQL" moniker until a surge of popularity in the early twenty -first
century,[2] triggered by the needs of Web 2.0 companies.[3][4][5] NoSQL databases are
increasingly used in big data and real-time web applications.[6] NoSQL systems are also
sometimes called "Not only SQL" to emphasize that they may support SQL-like query
languages, or sit alongside SQL database in a polyglot persistence architecture.[7][8]
Motivations for this approach include: simplicity of design, simpler "horizontal"
scaling to clusters of machines (which is a problem for relational databases), [2] and finer
control over availability. The data structures used by NoSQL databases (e.g. key -value,
wide column, graph, or document) are different from those used by default in relational
databases, making some operations faster in NoSQL. The particular suitability of a given
NoSQL database depends on the problem it must solve. Sometimes the data structures
used by NoSQL databases are also viewed as "more flexible" than relationa l database
tables.[9]
Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of
availability, partition tolerance, and speed. Barriers to the greater adoption of NoSQL stores
include the use of low-level query languages (instead of SQL, for instance the lack of ability
to perform ad-hoc joins across tables), lack of standardized interfaces, and huge previous
investments in existing relational databases. [10] Most NoSQL stores lack
true ACID transactions, although a few databases have made them central to their designs.
Instead, most NoSQL databases offer a concept of "eventual consistency" in which
database changes are propagated to all nodes "eventually" (typically within millis econds)
so queries for data might not return updated data immediately or might result in reading
data that is not accurate, a problem known as stale reads. [11] Additionally, some NoSQL
systems may exhibit lost writes and other forms of data loss.[12] Some NoSQL systems
provide concepts such as write-ahead logging to avoid data loss. [13] For distributed
transaction processing across multiple databases, data consistency is an even bigger
challenge that is difficult for both NoSQL and relational databases. Even current relationa l
databases "do not allow referential integrity constraints to span databases." [14] There are
few systems that maintain both ACID transactions and X/Open XA standards for distributed
transaction processing.

Contents

 1History
 2Types and examples of NoSQL databases
o 2.1Key-value store
o 2.2Document store
o 2.3Graph
o 2.4Object database
o 2.5Tabular
o 2.6Tuple store
o 2.7Triple/quad store (RDF) database
o 2.8Hosted
o 2.9Multivalue databases
 o 2.10Multimodel database
 3Performance
 4Handling relational data
o 4.1Multiple queries
o 4.2Caching, replication and non-normalized data
o 4.3Nesting data
 5ACID and join support
 6See also
 7References
 8Further reading
 9External links

History[edit]
The term NoSQL was used by Carlo Strozzi in 1998 to name his lightweight Strozzi NoSQL
open-source relational database that did not expose the standard Structured Query
Language (SQL) interface, but was still relational. [15] His NoSQL RDBMS is distinct from the
circa-2009 general concept of NoSQL databases. Strozzi suggests that, because the
current NoSQL movement "departs from the relational model altogether, it should therefore
have been called more appropriately 'NoREL', [16] referring to 'No Relational'.
Johan Oskarsson, then a developer at Last.fm, reintroduced the term NoSQL in early 2009
when he organized an event to discuss "open source distributed, non relational
databases".[17] The name attempted to label the emergence of an increasing number of non-
relational, distributed data stores, including open source clones of Google's
Bigtable/MapReduce and Amazon's Dynamo. Most of the early NoSQL systems did not
attempt to provide atomicity, consistency, isolation and durability guarantees, contrary to
the prevailing practice among relational database systems. [18]

Types and examples of NoSQL databases[edit]

There have been various approaches to classify NoSQL databases, each with different
categories and subcategories, some of which overlap. What follows is a basic classification
by data model, with examples:

 Column: Accumulo, Cassandra, Druid, HBase, Vertica.

 Document: Apache CouchDB, ArangoDB, BaseX, Clusterpoint, Couchbase, Cosmos
DB, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
 Key-value: Aerospike, Apache Ignite, ArangoDB, Berkeley
DB, Couchbase, Dynamo, FoundationDB, InfinityDB, MemcacheDB, MUMPS, Oracle
NoSQL Database, OrientDB, Redis, Riak, SciDB, SDBM/Flat File dbm, ZooKeeper
 Graph: AllegroGraph, ArangoDB, InfiniteGraph, Apache
Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso
A more detailed classification is the following, based on one from Stephen Yen: [19][20]

Type Notable examples of this type

Key-Value Apache Ignite, Coherence, eXtreme

Cache Scale, Hazelcast, Infinispan, Memcached, Velocity
 Type Notable examples of this type

Key-Value
ArangoDB, Aerospike
Store

Key-Value
Store
Oracle NoSQL Database, Dynamo, Riak, Voldemort
(Eventually-
Consistent)

Key-Value
Store FoundationDB, InfinityDB, LMDB, MemcacheDB
(Ordered)

Data-
Structures Redis
Server

Tuple Store Apache River, GigaSpaces

Object
Objectivity/DB, Perst, ZopeDB
Database

Document ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, IBM

Store Domino, MarkLogic, MongoDB, Qizx, RethinkDB

Wide Column
Amazon DynamoDB, Bigtable, Cassandra, Druid, HBase, Hypertable
Store

Native Multi-
model ArangoDB, Cosmos DB, OrientDB, MarkLogic
Database

Correlation databases are model-independent, and instead of row-based or column-based

storage, use value-based storage.
Key-value store[edit]
Main article: Key-value database
Key-value (KV) stores use the associative array (also known as a map or dictionary) as
their fundamental data model. In this model, data is represented as a collection o f key-
value pairs, such that each possible key appears at most once in the collection. [21][22]
The key-value model is one of the simplest non-trivial data models, and richer data models
are often implemented as an extension of it. The key-value model can be extended to a
discretely ordered model that maintains keys in lexicographic order. This extension is
computationally powerful, in that it can efficiently retrieve selective key ranges.[23]
Key-value stores can use consistency models ranging from eventual
consistency to serializability. Some databases support ordering of keys. There are various
hardware implementations, and some users maintain data in memory (RAM), while others
employ solid-state drives (SSD) or rotating disks (aka Hard Disk Drive (HDD)).
Document store[edit]
Main articles: Document-oriented database and XML database
The central concept of a document store is the notion of a "document". While each
document-oriented database implementation differs on the details of this definition, in
general, they all assume that documents encapsulate and encode data (or information) i n
some standard formats or encodings. Encodings in use include XML, YAML, and JSON as
well as binary forms like BSON. Documents are addressed in the database via a
unique key that represents that document. One of the other defining characteristics of a
document-oriented database is that in addition to the key lookup performed b y a key-value
store, the database also offers an API or query language that retrieves documents based
on their contents.
Different implementations offer different ways of organizing and/or grouping documents:

 Collections
 Tags
 Non-visible metadata
 Directory hierarchies
Compared to relational databases, for example, collections could be considered analogous
to tables and documents analogous to records. But they are different: every record in a
table has the same sequence of fields, while documents in a collection may have fields that
are completely different.
Graph[edit]
Main article: Graph database
This kind of database is designed for data whose relations are well represented as
a graph consisting of elements interconnected with a finite number of relations between
them. The type of data could be social relations, public transport links, road maps, network
topologies, etc.
Graph databases and their query language

Name Language(s) Notes

AllegroGraph SPARQL RDF triple store

Multi-model DBMS Document, Graph

ArangoDB AQL, JavaScript, GraphQL
database and Key-value store

DEX/Sparksee C++, Java, .NET, Python Graph database

 Name Language(s) Notes

FlockDB Scala Graph database

IBM DB2 SPARQL RDF triple store added in DB2 10

InfiniteGraph Java Graph database

Multi-model document
MarkLogic Java, JavaScript, SPARQL, XQuery
database and RDF triple store

Neo4j Cypher Graph database

OpenLink
C++, C#, Java, SPARQL Middleware and database engine hybrid
Virtuoso

Oracle SPARQL 1.1 RDF triple store added in 11g

Multi-model document and graph

OrientDB Java, SQL
database

OWLIM Java, SPARQL 1.1 RDF triple store

Profium Sense Java, SPARQL RDF triple store

Sqrrl Enterprise Java Graph database

Object database[edit]
Main article: Object database

 db4o
 GemStone/S
 InterSystems Caché
 JADE
 ObjectDatabase++
 ObjectDB
 Objectivity/DB
 ObjectStore
 ODABA
 Perst
 OpenLink Virtuoso
 Versant Object Database
 ZODB
Tabular [edit]

 Apache Accumulo
 Bigtable
 Apache Hbase
 Hypertable
 Mnesia
 OpenLink Virtuoso
Tuple store[edit]

 Apache River
 GigaSpaces
 Tarantool
 TIBCO ActiveSpaces
 OpenLink Virtuoso
Triple/quad store (RDF) database[edit]
Main articles: Triplestore and Named graph

 AllegroGraph
 Apache JENA (It is a framework, not a database)
 MarkLogic
 Ontotext-OWLIM
 Oracle NoSQL database
 Profium Sense
 Virtuoso Universal Server
Hosted[edit]

 Amazon DynamoDB
 Amazon SimpleDB
 Datastore on Google Appengine
 Clusterpoint database
 Cloudant Data Layer (CouchDB)
 Freebase
 Microsoft Azure Tables
 Microsoft Azure DocumentDB
 OpenLink Virtuoso
Multivalue databases[edit]

 D3 Pick database
 Extensible Storage Engine (ESE/NT)
 InfinityDB
 InterSystems Caché
 jBASE Pick database
 mvBase Rocket Software
 mvEnterprise Rocket Software
 Northgate Information Solutions Reality, the original Pick/MV Database
 OpenQM
 Revelation Software's OpenInsight
 UniData Rocket U2
 UniVerse Rocket U2
Multimodel database[edit]

 Apache Ignite [24][25]

 ArangoDB
 Couchbase
 FoundationDB
 MarkLogic
 OrientDB
 Cosmos DB

Performance[edit]
Ben Scofield rated different categories of NoSQL databases as follows: [26]

Data
Performance Scalability Flexibility Complexity Functionality
model

Key–value
high high high none variable (none)
store

Column-
oriented high high moderate low minimal
store

Document-
variable
oriented high high low variable (low)
(high)
store

Graph
variable variable high high graph theory
database

Relational relational
variable variable low moderate
database algebra

Performance and scalability comparisons are sometimes done with the YCSB benchmark.

Handling relational data [edit]

Since most NoSQL databases lack ability for joins in queries, the database
schema generally needs to be designed differently. There are three main techniques for
handling relational data in a NoSQL database. (See table Join and ACID Support for
NoSQL databases that support joins.)
Multiple queries[edit]
Instead of retrieving all the data with one query, it is common to do several queries to get
the desired data. NoSQL queries are often faster than traditional SQL qu eries so the cost of
having to do additional queries may be acceptable. If an excessive number of queries
would be necessary, one of the other two approaches is more appropriate.
Caching, replication and non-normalized data[edit]
Instead of only storing foreign keys, it is common to store actual foreign values along with
the model's data. For example, each blog comment might include the username in addition
to a user id, thus providing easy access to the username without requiring another lookup.
When a username changes however, this will now need to be changed in many places in
the database. Thus this approach works better when reads are much more common than
writes.[27]
Nesting data[edit]
With document databases like MongoDB it is common to put more data in a smaller
number of collections. For example, in a blogging application, one might choose to store
comments within the blog post document so that with a single retrieval one gets all the
comments. Thus in this approach a single document contains all the data you need for a
specific task.

ACID and join support[edit]

A database is marked as supporting ACID properties (Atomicity, Consistency, Isolation,
Durability) or join operations if the documentation for the database makes that claim. The
degree to which the capability is fully supported in a manner similar to most SQL databases
or the degree to which it meets the needs of a specific application is left up to the reader to
assess.

Database ACID Joins

Aerospike Yes No

Apache Ignite Yes Yes

ArangoDB Yes Yes

CouchDB Yes Yes

Db2 Yes Yes

InfinityDB Yes No

LMDB Yes No
MarkLogic Yes Yes [nb 1]

MongoDB Yes Yes

OrientDB Yes Yes [nb 2]

1. ^ Joins do not necessarily apply to document databases, but MarkLogic can do joins using
semantics. [28]
2. ^ OrientDB can resolve 1:1 joins using links by storing direct links to foreign records. [29]