NoSQL

This article may need to be rewritten entirely to comply with Wikipedia's quality standards. You can help. The discussion page may contain suggestions. (May 2012)

In computing, NoSQL is a class of database management system identified by its non-adherence to the widely used relational database management system (RDBMS) model:

• It does not use SQL as its query language

NoSQL database systems rose alongside major internet companies, such as Google, Amazon, and Facebook, which had significantly different challenges in dealing with huge quantities of data that the traditional RDBMS solutions could not cope with. NoSQL database systems are developed to manage large volumes of data that do not necessarily follow a fixed schema. Data is partitioned among different machines (for performance questions and because of its size) so JOIN operations are not usable and ACID guarantees are not given.

• It may not give full ACID guarantees

Usually only eventual consistency is guaranteed or transactions limited to single data items. This means that given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system.

• It has a distributed, fault-tolerant architecture

Several NoSQL systems employ a distributed architecture, with the data held in a redundant manner on several servers. In this way, the system can easily scale out by adding more servers, and failure of a server can be tolerated. This type of database typically scales horizontally and is used for managing big amounts of data, when the performance and real-time nature is more important than consistency (as indexing a large number of documents, serving pages on high-traffic websites, and delivering streaming media).

NoSQL database systems are often highly optimized for retrieve and append operations and often offer little functionality beyond record storage (e.g. key-value stores). The reduced run time flexibility compared to full SQL systems is compensated by significant gains in scalability and performance for certain data models.

In short, NoSQL database management systems are useful when working with a huge quantity of data and the data's nature does not require a relational model for the data structure. The data could be structured, but it is of minimal importance and what really matters is the ability to store and retrieve great quantities of data, and not the relationships between the elements. For example, to store millions of key-value pairs in one or a few associative arrays or to store millions of data records. This is particularly useful for statistical or real-time analyses for growing list of elements (such as Twitter posts or the Internet server logs from a big group of users).

History

Carlo Strozzi used the term NoSQL in 1998 to name his lightweight, open-source relational database that did not expose the standard SQL interface.^[1] (Strozzi suggests that, as the current NoSQL movement "departs from the relational model altogether; it should therefore have been called more appropriately 'NoREL', or something to that effect.")^[2]

Eric Evans, a Rackspace employee, reintroduced the term NoSQL in early 2009 when Johan Oskarsson of Last.fm wanted to organize an event to discuss open-source distributed databases.^[3] The name attempted to label the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACID (atomicity, consistency, isolation, durability) guarantees, which are the key attributes of classic relational database systems such as Sybase, IBM DB2, MySQL, Microsoft SQL Server, PostgreSQL, Oracle RDBMS, Informix, Oracle Rdb, etc.

In 2011, work began on UnQL (Unstructured Query Language), a specification for a query language for NoSQL databases.^[4] It is built to query collections (versus tables) of documents (versus rows) with loosely defined fields (versus columns). UnQL is claimed^{[by whom?]} to be a superset of SQL within which SQL is a very constrained type of UnQL for which the queries always return the same fields (same number, names and types). However, UnQL does not cover the data definition language (DDL) SQL statements like CREATE TABLE or CREATE INDEX.^[5]

Architecture

Typical modern relational databases have shown poor performance on certain data-intensive applications, including indexing a large number of documents, serving pages on high-traffic websites, and delivering streaming media.^[6] Typical RDBMS implementations are tuned either for small but frequent read/write transactions or for large batch transactions with rare write accesses. NoSQL, on the other hand, can service heavy read/write workloads.^[6] Real-world NoSQL deployments include Digg's 3 TB for green badges (markers that indicate stories voted for by others in a social network; this lasted less than three months and was abandoned.),^[7] the 6 TB database of the European Commission's ENSEMBLE platform for air quality models evaluation and intercomparison^[8] and Facebook's 50 TB for inbox search.^[9]

NoSQL architectures often provide weak consistency guarantees, such as eventual consistency, or transactions restricted to single data items. Some systems, however, provide full ACID guarantees in some instances by adding a supplementary middleware layer (e.g., AppScale and CloudTPS).^[10][11] Two systems have been developed that provide snapshot isolation for column stores: Google's Percolator system based on BigTable,^[12] and a transactional system for HBase called "HBaseSI" developed at the University of Waterloo.^{[13] [14]} These systems, developed independently, use similar concepts to achieve multi-row distributed ACID transactions with snapshot isolation guarantee for the underlying column store, without the extra overhead of data management, middleware system deployment, or maintenance introduced by the middleware layer.

Several NoSQL systems employ a distributed architecture, with the data held in a redundant manner on several servers, often using a distributed hash table. In this way, the system can readily scale out by adding more servers, and failure of a server can be tolerated.^[15]

Some NoSQL advocates^[who?] promote very simple interfaces such as associative arrays or key-value pairs. Other systems, such as native XML databases, promote support of the XQuery standard.^{[citation needed]} Newer systems such as CloudTPS also support join queries.^[16]

Taxonomy

It has been suggested that this article or section be merged into Comparison of structured storage software. (Discuss) Proposed since March 2011.

This section may require cleanup to meet Wikipedia's quality standards. No cleanup reason has been specified. Please help improve this section if you can; the talk page may contain suggestions. (March 2010)

Often, NoSQL databases are categorized according to the way they store the data and fall under categories such as key-value stores, BigTable implementations, document store databases, and graph databases. NoSQL database systems rose alongside major internet companies, such as Google, Amazon, Twitter, and Facebook which had significantly different challenges in dealing with data that the traditional RDBMS solutions could not cope with (although most of Facebook's infrastructure is built on SQL databases^[17] and so is Twitter's ^[18]).^{[citation needed]} With the rise of the real-time web, there was a need to provide curated information out of large volumes of data which more or less followed similar horizontal structures. These companies realized that performance and real-time nature was more important than consistency, which traditional relational databases were spending a high amount of processing time to achieve.^{[citation needed]} As such, NoSQL databases are often highly optimized for retrieve and append operations and often offer little functionality beyond record storage (e.g. key-value stores). The reduced run time flexibility compared to full SQL systems is compensated by significant gains in scalability and performance for certain data models.^{[citation needed]}

NoSQL implementations can be categorized by their manner of implementation:

Document store

A document-oriented database stores, retrieves, and manages semi structured data. The element of data is called document.

Different implementations offer different ways of organizing and/or grouping documents:

• Collections
• Tags
• Non-visible Metadata
• Directory hierarchies

Compared to relational databases we could say, for example, that collections are to tables as documents are to records. But there is one big difference: every record in a table has the same number of fields, while documents in a collection could have completely different fields.

Encodings in use include XML, YAML, JSON, and BSON, as well as binary forms like PDF and Microsoft Office documents (MS Word, Excel, and so on).

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, beyond the simple key-document (or key-value) lookup that you can use to retrieve a document, the database will offer an API or query language that will allow you to retrieve documents based on their contents.

Graph

This kind of database is designed for data whose relations are well represented as a graph (elements interconnected with an undetermined number of relations between them). The kind of data could be social relations, public transport links, road maps or network topologies, by example.

Key-value store

Key-value stores allow the application to store its data in a schema-less way. The data could be stored in a datatype of a programming language or an object. Because of this, there is no need for a fixed data model.^{[19] [20]} The following types exist:

Eventually‐consistent key‐value store

• Apache Cassandra
• Dynamo
• Hibari
• OpenLink Virtuoso
• Project Voldemort
• Riak ^[21]

Hierarchical key-value store

• GT.M^[22]
• InterSystems Caché

Hosted services

• Freebase
• OpenLink Virtuoso
• Datastore on Google Appengine
• Amazon DynamoDB‎
• Cloudant Data Layer (CouchDB)

Key-value cache in RAM

• memcached
• OpenLink Virtuoso
• Oracle Coherence
• NCache
• Redis
• Hazelcast
• Tuple space
• Velocity

Key-value stores on solid state or rotating disk

• BigTable
• CDB
• Keyspace
• LevelDB
• membase
• MemcacheDB
• MongoDB
• OpenLink Virtuoso
• Tarantool
• Tokyo Cabinet
• TreapDB
• Tuple space

Ordered key-value stores

• Berkeley DB
• IBM Informix C-ISAM
• InfinityDB
• MemcacheDB
• NDBM

Multivalue databases

• Northgate Information Solutions Reality, the original Pick/MV Database
• Extensible Storage Engine (ESE/NT)
• jBASE
• OpenQM
• Revelation Software's OpenInsight
• Rocket U2
• D3 Pick database
• InterSystems Caché
• InfinityDB

Object database

• db4o
• Eloquera
• GemStone/S
• InterSystems Caché
• JADE
• NeoDatis ODB
• ObjectDB
• Objectivity/DB
• ObjectStore
• OpenLink Virtuoso
• Versant Object Database
• Wakanda
• ZODB

RDF database

• Meronymy SPARQL Database Server

Tabular

• BigTable
• Apache Hadoop
• Apache Hbase
• Hypertable
• Mnesia
• OpenLink Virtuoso

Tuple store

• Apache River
• OpenLink Virtuoso
• Tarantool

See also

• CAP theorem
• Comparison of object database management systems
• Comparison of structured storage software
• Faceted search
• List of object database management systems
• Triplestore
• RDF Database
• Distributed cache

References

External links

• NoSQL whitepaper
• NoSQL general introduction article
• Managing Data Relationships in Distributed Cache
• How RDF Databases Differ from Other NoSQL Solutions