Return to SQL, Cloud databases or Database topics
NoSQL Models refer to a variety of database systems that do not use the traditional Relational Database Management Systems (RDBMS) approach of tables and structured query language (SQL). Instead, NoSQL databases are designed to handle a wide range of data models, including document-oriented, key-value, column-family, and graph-based models. They are particularly useful for applications requiring flexible schema designs and database scalability.
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:
Replace with navbar_database
A more detailed classification is the following, based on one from Stephen Yen:<ref>
</ref><ref>
</ref>
{]] | " class="wikitable sortable" | - ! Type !! Notable examples of this type | - | Key-Value Cache | nosql | [[Apache Ignite, Oracle Coherence | Coherence, IBM WebSphere eXtreme Scale | eXtreme Scale, Hazelcast, Infinispan, Memcached, Velocity (memory cache) | Velocity ]] | - | Key-Value Store | nosql | [[ArangoDB, Aerospike database | Aerospike ]] | - | Key-Value Store (Eventually-Consistent) | nosql | [[Oracle NoSQL Database, Dynamo (storage system) | Dynamo, Riak, Voldemort (distributed data store) | Voldemort ]] | - | Key-Value Store (Ordered) | nosql | [[FoundationDB, InfinityDB, Lightning Memory-Mapped Database | LMDB, MemcacheDB ]] | - | Data-Structures Server | nosql | [[Redis ]] | - | Tuple Store | nosql | [[Jini | Apache River, GigaSpaces ]] | - | Object Database | nosql | [[Objectivity/DB, Perst, Zope Object Database | ZopeDB ]] | - | Document Store | nosql | [[ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, Lotus Notes | IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB ]] | - | [[Wide column store | Wide Column Store ]] | nosql | [[Amazon DynamoDB, Bigtable, Apache Cassandra | Cassandra, Druid (open-source data store) | Druid, Apache HBase | HBase, Hypertable ]] | - | Native Multi-model Database | nosql | [[ArangoDB, Cosmos DB, OrientDB ]] | } [[Correlation databases are model-independent, and instead of row-based or column-based storage, use value-based storage.
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 of key-value pairs, such that each possible key appears at most once in the collection.<ref>
</ref><ref>
</ref>
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 Lexicographical order | lexicographic order. This extension is computationally powerful, in that it can efficiently retrieve selective key ranges.<ref>
</ref>
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 hard disk drive | rotating disks (aka Hard Disk Drive (HDD)).
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) in 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 by 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:
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.
Main: Graph database
This kind of database is designed for data whose relations are well represented as a graph (discrete mathematics) | 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 {]] | " class="wikitable sortable" ! Name !! Language(s) !! Notes | - | [[AllegroGraph ]] | nosql | [[SPARQL ]] | nosql | [[Resource Description Framework | RDF triple store
]] | [[- ]] | [[ [[ArangoDB]] ]] | [[]] | [[ AQL, [[JavaScript]], [[GraphQL]] ]] | [[]] | [[ Multi-model DBMS [[Document-oriented database]] | [[Document]], [[Graph database]] and [[Key-value store]] ]] | [[- ]] | [[ [[DEX (Graph database)]] | [[DEX/Sparksee]] ]] | [[]] | [[ [[C++]], [[Java (programming language)]] | [[Java]], [[.NET Framework]] | [[.NET]], [[Python (programming language)]] | [[Python]] ]] | [[]] | [[ [[Graph database]] ]] | [[- ]] | [[ [[FlockDB]] ]] | [[]] | [[ [[Scala (programming language)]] | [[Scala]] ]] | [[]] | [[ [[Graph database]] ]] | [[- ]] | [[ [[IBM DB2]] ]] | [[]] | [[ [[SPARQL]] ]] | [[]] | [[ [[Resource Description Framework]] | [[RDF]] triple store added in DB2 10 ]] | [[- ]] | [[ [[InfiniteGraph]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]] ]] | [[]] | [[ [[Graph database]] ]] | [[- ]] | [[ [[MarkLogic]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]], [[JavaScript]], [[SPARQL]], [[XQuery]] ]] | [[]] | [[ Multi-model [[Document-oriented database]] | [[document database]] and [[Resource Description Framework]] | [[RDF]] triple store ]] | [[- ]] | [[ [[Neo4j]] ]] | [[]] | [[ [[Cypher Query Language]] | [[Cypher]] ]] | [[]] | [[ [[Graph database]] ]] | [[- ]] | [[ [[Virtuoso Universal Server]] | [[OpenLink Virtuoso]] ]] | [[]] | [[ [[C++]], [[C Sharp (programming language)]] | [[C#]], [[Java (programming language)]] | [[Java]], [[SPARQL]] ]] | [[]] | [[ [[Middleware]] and [[database engine]] hybrid ]] | [[- ]] | [[ [[Oracle Database]] | [[Oracle]] ]] | [[]] | [[ [[SPARQL]] | [[SPARQL 1.1]] ]] | [[]] | [[ [[Resource Description Framework]] | [[RDF]] triple store added in 11g ]] | [[- ]] | [[ [[OrientDB]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]], SQL ]] | [[]] | [[ Multi-model [[Document-oriented database]] | [[document]] and [[graph database]] ]] | [[- ]] | [[ [[Ontotext]] | [[OWLIM]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]], [[SPARQL]] | [[SPARQL 1.1]]]] | [[]] | [[ [[Resource Description Framework]] | [[RDF]] triple store ]] | [[- ]] | [[ [[Profium]] | [[Profium Sense]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]], [[SPARQL]] ]] | [[]] | [[ [[Resource Description Framework]] | [[RDF]] triple store ]] | [[- ]] | [[ [[sqrrl]] | [[Sqrrl Enterprise]] ]] | [[]] | [[ [[Java (programming language)]] | [[Java]] ]] | [[]] | [[ [[Graph database]]]] | } === Object database === * [[db4o
Return to GitHub star ranking for organizations, GitHub star ranking for repositories, GitOps or GitHub
NoSQL (originally meaning "non-SQL" or "non-relational") refers to a type of database design that stores and retrieves data differently from the traditional table-based structure of relational databases. Unlike relational databases, which organize data into rows and columns like a spreadsheet, NoSQL databases use a single data structure—such as key–value pairs, wide columns, graphs, or documents—to hold information. Since this non-relational design does not require a fixed schema, it scales easily to manage large, often unstructured datasets. NoSQL systems are sometimes called "Not only SQL" because they can support SQL-like query languages or work alongside SQL databases in polyglot-persistent setups, where multiple database types are combined. Non-relational databases date back to the late 1960s, but the term "NoSQL" emerged in the early 2000s, spurred by the needs of Web 2.0 companies like social media platforms.
NoSQL databases are popular in big data and real-time web applications due to their simple design, ability to scale across clusters of machines (called horizontal scaling), and precise control over data availability. These structures can speed up certain tasks and are often considered more adaptable than fixed database tables. However, many NoSQL systems prioritize speed and availability over strict consistency (per the CAP theorem), using eventual consistency—where updates reach all nodes eventually, typically within milliseconds, but may cause brief delays in accessing the latest data, known as stale reads. While most lack full ACID transaction support, some, like MongoDB, include it as a key feature.
Cloud Monk recommends the following YouTube video:
Package Managers Artifact Registries and Repos: