Since this non-relational database design does not require a schema, it offers rapid scalability to manage large and typically unstructured data sets.
[3][4] Non-relational databases have existed since the late 1960s, but the name "NoSQL" was only coined in the early 2000s,[5] triggered by the needs of Web 2.0 companies.
[8] Motivations for this approach include simplicity of design, simpler "horizontal" scaling to clusters of machines (which is a problem for relational databases),[5] finer control over availability, and limiting the object-relational impedance mismatch.
[10] Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability, partition tolerance, and speed.
[18] Limitations within the interface environment are overcome using semantic virtualization protocols, such that NoSQL services are accessible to most operating systems.
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".
[22] 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 DynamoDB.
Another defining characteristic of a document-oriented database is an API or query language to retrieve documents based on their contents.
Examples of data include social relations, public transport links, road maps, network topologies, etc.
Performance evaluation must pay attention to the right benchmarks such as production configurations, parameters of the databases, anticipated data volume, and concurrent user workloads.
Ben Scofield rated different categories of NoSQL databases as follows:[30] Performance and scalability comparisons are most commonly done using the YCSB benchmark.
Different NoSQL databases, such as DynamoDB, MongoDB, Cassandra, Couchbase, HBase, and Redis, exhibit varying behaviors when querying non-indexed fields.
Systems like Elasticsearch use inverted indexes for efficient text-based searches, but they can still require full scans for non-indexed fields.
This behavior reflects the design focus of many NoSQL systems on scalability and efficient key-based operations rather than optimized querying for arbitrary fields.