In computing, NoSQL (sometimes expanded to "not only SQL") is a broad class of database management systems that differ from the classic model of the relational database management system (RDBMS) in some significant ways, most important being they do not use SQL as their query language. These data stores may not require fixed table schemas, usually avoid join operations, and typically scale horizontally. Academic researchers typically refer to these databases as structured storage,[1][2][3][4] a term that includes classic relational databases as a subset.
Often, NoSQL databases are categorized according to the way they store the data and it falls under categories such as Key-Value stores, BigTable Implementations, Document-Store databases and Graph Database. The rise of NoSQL database systems alongside with rise of major internet companies, such Google, Amazon, Twitter and Facebook which had significantly different challenges in dealing with data which the traditional RDBMS solutions could not cope with. With the rise of real-time web and 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.
Contents |
Carlo Strozzi used the term NoSQL in 1998 to name his lightweight, open-source relational database that did not expose the standard SQL interface.[5] (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.")[6]
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.[7] 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.[8] It is built to query collections (versus tables) of documents (versus rows) with loosely defined fields (versus columns). UnQL is 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
.[9]
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.[10] 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.[10] Real-world NoSQL deployments include Digg's 3 TB for green badges (markers that indicate stories voted for by others in a social network)[11] and Facebook's 50 TB for inbox search.[12]
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).[13][14] Two systems have been developed that provide snapshot isolation for column stores: Google's Percolator system based on BigTable,[15] and a transactional system for HBase developed at the University of Waterloo.[16] 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.[17]
Some NoSQL advocates 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. Newer systems such as CloudTPS also support join queries.[18]
NoSQL implementations can be categorized by their manner of implementation:
Name | Language | Notes |
---|---|---|
BaseX | Java, XQuery | XML database |
Clusterpoint | C++ | geared for Full text search |
Apache CouchDB | Erlang | |
eXist | XQuery | XML database |
Jackrabbit | Java | |
Lotus Notes and IBM Lotus Domino | LotusScript, Java, IBM X Pages, others | MultiValue |
MarkLogic Server | XQuery | XML database |
MongoDB | C++ | BSON (Binary format JSON) |
OpenLink Virtuoso | C++, C#, Java, SPARQL | middleware and database engine hybrid that combines the functionality of a traditional RDBMS, ORDBMS, Graph Database, virtual database, RDF, XML, free-text, web application server and file server |
OrientDB | Java | |
SimpleDB | Erlang | |
Terrastore | Java |
Name | Language | Notes |
---|---|---|
AllegroGraph | SPARQL | RDF GraphStore |
DEX | Java, C++ | High-performance Graph Database |
FlockDB | Scala | |
InfiniteGraph | Java | High-performance, scalable, distributed Graph Database |
Neo4j | Java | |
OpenLink Virtuoso | C++, C#, Java, SPARQL | middleware and database engine hybrid that combines the functionality of a traditional RDBMS, ORDBMS, Graph Database, virtual database, RDF, XML, free-text, web application server and file server |
OrientDB | Java | |
Pregel | ||
Sones GraphDB | C# | Graph database with query language called GraphQL |
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:
|