To maintain varied schema is not possible with traditional database, where NoSql comes into picture.
- Key-Value : CouchDB, Oracle NoSQL Database, Dynamo, FoundationDB, HyperDex, MemcacheDB, Redis, Riak, FairCom c-treeACE, Aerospike, OrientDB, MUMPS
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. The key-value model is one of the simplest non-trivial data models, and richer data models are often implemented on top of it. The key-value model can be extended to an ordered model that maintains keys in lexicographic order. This extension is powerful, in that it can efficiently process key ranges. Key-value stores can use consistency models ranging from eventual consistency to serializability. Some support ordering of keys. Some maintain data in memory (RAM), while others employ solid-state drives or rotating disks.
- Document : Clusterpoint, Apache CouchDB, Couchbase, DocumentDB, HyperDex, Lotus Notes, MarkLogic, MongoDB, OrientDB, Qizx
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 offers an API or query language that retrieves documents based on their contents
Different implementations offer different ways of organizing and/or grouping documents:
- Non-visible metadata
- Directory hierarchies
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.
- Graph : Allegro, Neo4J, InfiniteGraph, OrientDB, Virtuoso, Stardog
This kind of database is designed for data whose relations are well represented as a graph (elements interconnected with an undetermined number of relations between them). The kind of data could be social relations, public transport links, road maps or network topologies
- Big Table / Column : Accumulo, Cassandra, Druid, HBase, Vertica
- Multi-model : OrientDB, FoundationDB, ArangoDB, Alchemy Database, CortexDB
- Others (Adding to above list): Object Databases, XML Databases, Multidimensional Databases, Multivalue Databases, Grid & cloud database solutions and few more
RDBMS has ACID (Atomicity, Consistency, Isolation, Durability) properties. NoSQL has BASE (Basically Available, Soft state, Eventual consistency) properties J
CAP Theorem – Consistency, Availability and Partition tolerance
It is impossible to provide all three properties to the DFS.
C – Commits are atomic across the entire DFS
Consistency means, same data same time. All data is updated and every read would get more recent write.
A – Remains accessible and operated at all times
Availability means, any request comes to the system, it should respond all the time. For example, airline service provides will take booking from all the centers and end of the day, they will assess whether they are overbooked or under booked. Then the airline management will take the situation accordingly.
P – Only a total network failure can cause the system to report incorrectly
Fault tolerance in the lines of hadoop framework. This guarantees the high availability
Choice of these newsql databases is based on the business requirement.
PA – Cassandra, couchDB, Dynamo, Riak
CP – Hbase, MongoDB, Redis, Big Table
CA – RDBMS