History
The term NoSQL was used in 1998 as the name for a lightweight open source relational database that did not expose a SQL interface. Its author, Carlo Strozzi, claims that as the NoSQL movement "departs from the relational model altogether it should therefore have been called more appropriately 'NoREL', or something to that effect."[5]
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.[6] The name attempted to label the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACIDguarantees (the key attributes of classic relational database systems such as IBM DB2, MySQL, Microsoft SQL Server, PostgreSQL, Oracle RDBMS, etc).
The "no:sql(east)" conference 2009 in Atlanta had a strong influence on the NoSQL debate. Its self-conception was "a conference of non-relational data stores", and its motto was "select fun, profit from real_world where relational=false;". Thus, the most common interpretation of "NoSQL" is "non-relational". Another solution is to use the term "NoREL", which is not widely used. Either way, NoSQL is not meant as anti-RDBMS but emphasizes the advantages of Key-Value Stores, Document Databases, and Graph Databases.[citation needed]
[edit]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.[7] 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, services heavy read/write workloads.[7] Real-world NoSQL deployments include Digg's 3 TB for green badges (markers that indicate stories upvoted by others in a social network),[8] Facebook's 50 TB for inbox search, and eBay's 2 PB overall data.
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., CloudTPS).[9] Two systems have been developed that provide snapshot isolation for column stores: Google's Percolator system based on BigTable[10], and a transactional system for HBase developed at the University of Waterloo[11]. 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.[12]
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] <>
[edit]Taxonomy
NoSQL implementations can be categorized by their manner of implementation:
[edit]Key/value store on disk
[edit]Key/value cache in RAM
[edit]Eventually‐consistent key‐value store
[edit]Hierarchical key-value store
[edit]Ordered key-value store
[edit]Multivalue databases
[edit]Tabular
[edit]Tuple store
[edit]See also