Return to Cloud databases or Database topics
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:
Related Topics:
A more detailed classification is the following, based on one from Stephen Yen:<ref>
</ref><ref>
</ref>
| Type | Notable examples of this type |
|---|---|
| Key-Value Cache | Apache Ignite, Coherence, eXtreme Scale, Hazelcast, Infinispan, Memcached, Velocity |
| Key-Value Store | ArangoDB, Aerospike |
| Key-Value Store (Eventually-Consistent) | Oracle NoSQL Database, Dynamo, Riak, Voldemort |
| Key-Value Store (Ordered) | FoundationDB, InfinityDB, LMDB, MemcacheDB |
| Data-Structures Server | Redis |
| Tuple Store | Apache River, GigaSpaces |
| Object Database | Objectivity/DB, Perst, ZopeDB |
| Document Store | ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB |
| Wide Column Store | Amazon DynamoDB, Bigtable, Cassandra, Druid, HBase, Hypertable |
| Native Multi-model Database | 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 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 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 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
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: