This is a simple phone directory. The person’s name is the key, and the phone number is the value.<\/p>\n
This type of database is very quick to query, due to its simplicity.<\/p>\n
The key-value model is well suited to storing things like user profiles and session info on a website, blog comments, telecom directories, IP forwarding tables, shopping cart contents on e-commerce sites, and more.<\/p>\n
Examples of key-store\u00a0database management systems\u00a0include:<\/p>\n
- \n
- Redis<\/a><\/li>\n
- Oracle NoSQL Database<\/a><\/li>\n
- Voldemorte<\/a><\/li>\n
- Aerospike<\/a><\/li>\n
- Oracle Berkeley DB<\/a><\/li>\n<\/ul>\n
Document Store<\/h2>\n
A\u00a0document store database<\/a>\u00a0uses a document-oriented model to store data. It is similar to a\u00a0key-value database in that it uses a key-value approach. The difference is that, the value in a\u00a0document store database consists of semi-structured data.<\/p>\n
Also known as a document oriented or aggregate database, a document store database stores each record and its associated data within a single document<\/i>. Each document contains semi-structured data that can be queried against using various\u00a0query and analytics\u00a0tools of the DBMS<\/a>.<\/p>\n
The documents in document stores are usually\u00a0XML or JSON, but some DBMSs use other languages, such as BSON, YAML, etc.<\/p>\n
Here’s an\u00a0example of a document written in\u00a0JSON:<\/p>\n
{\r\n '_id' : 1,\r\n 'artistName' : { 'Iron Maiden' },\r\n 'albums' : [\r\n {\r\n 'albumname' : 'The Book of Souls',\r\n 'datereleased' : 2015,\r\n 'genre' : 'Hard Rock'\r\n }, {\r\n 'albumname' : 'Killers',\r\n 'datereleased' : 1981,\r\n 'genre' : 'Hard Rock'\r\n }, {\r\n 'albumname' : 'Powerslave',\r\n 'datereleased' : 1984,\r\n 'genre' : 'Hard Rock'\r\n }, {\r\n 'albumname' : 'Somewhere in Time',\r\n 'datereleased' : 1986,\r\n 'genre' : 'Hard Rock'\r\n }\r\n ]\r\n}<\/pre>\nIn a document store, this\u00a0document can\u00a0be retrieved by referring to the
_id<\/code>.<\/p>\nDocument store databases can be used for a wide variety of use cases. They\u00a0are ideal for content management systems, blogging platforms, and other web applications.<\/p>\n
They are also well suited for user generated content such as blog comments, chat sessions, tweets, ratings, etc.<\/p>\n
Document stores are also great\u00a0for providing\u00a0real time\u00a0analytics and other reporting features.<\/p>\n
Here are examples of document store\u00a0DBMSs.<\/p>\n
- \n
- MongoDB<\/a><\/li>\n
- DocumentDB<\/a><\/li>\n
- CouchDB<\/a><\/li>\n
- MarkLogic<\/a><\/li>\n
- OrientDB<\/a><\/li>\n<\/ul>\n
Column Store<\/h2>\n
A column store database<\/a> is a type of database that stores\u00a0data using a column oriented model.<\/p>\n
Column stores work in a similar fashion to relational databases<\/a> in that they have rows, columns, and tables (also known as column families<\/i>). However, these work differently in column store databases.<\/p>\n
In a column store database,\u00a0the columns in\u00a0each row are contained within that row. Each row can have\u00a0different columns to the other rows. They can be in a different order, then can even have different data types, etc.<\/p>\n
Here’s a diagram to demonstrate\u00a0this:<\/p>\n
![\"Diagram](\"https:\/\/database.guide\/wp-content\/uploads\/2016\/06\/wide_column_store_database_example_column_family-1.png\")
<\/a>A column family containing 3 rows. Each row contains its own set of columns.<\/figcaption><\/figure>\n This method of storing data can be extremely quick to load and query.<\/p>\n
Columnar databases can also store\u00a0massive amounts of data, and they\u00a0can be scaled easily using massively parallel processing (MPP<\/a>),\u00a0which involves having data spread across a large cluster of machines.<\/p>\n
Examples of column store databases include:<\/p>\n
- \n
- Bigtable<\/a><\/li>\n
- Cassandra<\/a><\/li>\n
- HBase<\/a><\/li>\n
- Vertica<\/a><\/li>\n
- Druid<\/a><\/li>\n
- Accumulo<\/a><\/li>\n
- Hypertable<\/a><\/li>\n<\/ul>\n
Graph<\/h2>\n
Graph databases<\/a> use\u00a0a graphical\u00a0model to\u00a0represent and store the data.<\/p>\n
Here’s a\u00a0basic\u00a0example of how graph databases store and present data:<\/p>\n
![\"Screenshot](\"https:\/\/database.guide\/wp-content\/uploads\/2016\/06\/graph_database_relationship_example.png\")
<\/a>Example of a simple graph database.<\/figcaption><\/figure>\n The circles are nodes<\/dfn> – they contain the data. The arrows represent the relationships that each node has with other\u00a0nodes.<\/p>\n
Graph databases are an excellent choice for working with connected data – data that contains\u00a0lots of interconnected relationships. In fact, graph databases are much more suited to displaying relational data than relational databases.<\/p>\n
Graph databases are very well suited to applications like social networks, realtime product recommendations, network diagrams, fraud detection, access management, and more.<\/p>\n
As with most NoSQL databases, there’s no fixed schema<\/a> as such. \u00a0Any “schema” is simply a reflection of the data that has been entered. As more varied data is entered, the schema grows accordingly.<\/p>\n
Examples of graph databases include\u00a0Neo4j<\/a>,\u00a0Blazegraph<\/a>, and\u00a0OrientDB<\/a>.<\/p>\n
Also check out this list of over 40 graph database management systems<\/a>.<\/p>\n
Multi\u00a0Model<\/h2>\n
Some databases include features\/characteristics of more than one data model. These databases are usually categorised under one\u00a0or both of the models they use. They can also be referred to\u00a0as multi\u00a0model databases.<\/p>\n
Some examples of multi\u00a0model databases include:<\/p>\n
- \n
- OrientDB<\/a>. OrientDB combines\u00a0a graph model with\u00a0a document model.<\/li>\n
- ArangoDB<\/a>. Uses key\/value, document, and graph models.<\/li>\n
- Virtuoso<\/a>. Combines relational, graph, and document models.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
NoSQL databases are often categorised under four main types. Some databases are a mix between different types, but in general, they fit under\u00a0the following\u00a0main categories.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,43],"tags":[42],"class_list":["post-1104","post","type-post","status-publish","format-standard","hentry","category-database-concepts","category-nosql","tag-nosql"],"_links":{"self":[{"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/posts\/1104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/comments?post=1104"}],"version-history":[{"count":5,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/posts\/1104\/revisions"}],"predecessor-version":[{"id":1111,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/posts\/1104\/revisions\/1111"}],"wp:attachment":[{"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/media?parent=1104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/categories?post=1104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/database.guide\/wp-json\/wp\/v2\/tags?post=1104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- ArangoDB<\/a>. Uses key\/value, document, and graph models.<\/li>\n
- Cassandra<\/a><\/li>\n
- DocumentDB<\/a><\/li>\n
- Oracle NoSQL Database<\/a><\/li>\n