The primary way in which NoSQL differ from RDBMS is the data model. When compared with relational DB they are more scalable and they are designed to address Agile sprints, huge amount of data, quick iteration, and frequent code pushes.
The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply such as: schema-free, easy replication support, simple API, eventually consistent / BASE , a huge amount of data and more.
There are dozen of NoSQL databases, but we can primarily classify them into 3 categories
photo credit : couchdb
A graph database stores data in a graph. It is used to store highly connected data like in Social network(Facebook). Data is modeled as a network of relationships between specific elements.
Neo4j is a leading provider of graph database.Neo4j is a robust (fully ACID) transactional property graph database. For connected data operations, Neo4j claims to run a thousand times faster than relational databases.
photo credit :Neo4j
Key - Value and Wide Column Models
From a data model perspective, key - value stores are the most basic type of NoSQL database. Every item in the database is stored as an attribute name, or key, together with its value.
Please click here to find out how Workday is using SQL database to achieve NoSQL benefit.
NoSQL vs. SQL Summary
Data Storage Model
One type (SQL database) with minor variations
Developed in 1970s to deal with first wave of data storage applications
MySQL, Postgres, Oracle Database
Individual records (e.g., "employees") are stored as rows in tables, with each column storing a specific piece of data about that record (e.g., "manager," "date hired," etc.), much like a spreadsheet. Separate data types are stored in separate tables, and then joined together when more complex queries are executed. For example, "offices" might be stored in one table, and "employees" in another. When a user wants to find the work address of an employee, the database engine joins the "employee" and "office" tables together to get all the information necessary.
Structure and data types are fixed in advance.
Vertically, meaning a single server must be made increasingly powerful in order to deal with increased demand. It is possible to spread SQL databases over many servers, but significant additional engineering is generally required.
Mix of open-source (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database)
Yes, updates can be configured to complete entirely or not at all
Specific language using Select, Insert, and Update statements, e.g. SELECT fields FROM table WHERE…
Can be configured for strong consistency
Many different types including key-value stores, document databases, wide-column stores, and graph databases
Developed in 2000s to deal with limitations of SQL databases, particularly concerning scale, replication and unstructured data storage
MongoDB, Cassandra, HBase, Neo4j
Varies based on database type. For example, key-value stores function similarly to SQL databases, but have only two columns ("key" and "value"), with more complex information sometimes stored within the "value" columns. Document databases do away with the table-and-row model altogether, storing all relevant data together in single "document" in JSON, XML, or another format, which can nest values hierarchically.
Typically dynamic. Records can add new information on the fly, and unlike SQL table rows, dissimilar data can be stored together as necessary. For some databases (e.g., wide-column stores), it is somewhat more challenging to add new fields dynamically.
Horizontally, meaning that to add capacity, a database administrator can simply add more commodity servers or cloud instances. The database automatically spreads data across servers as necessary
In certain circumstances and at certain levels (e.g., document level vs. database level)
Many of the NoSQL databases are accessible in a RESTful way, so you make your database connection through a URI, and the queries and commands are HTTP calls. MongoDB is an exception. Its default is to use TCP for database interactions, although there’s at least one HTTP API available, as well. CouchDB and MongoDB provide language-specific APIs that let you write and execute queries and updates without having to worry about writing the HTTP calls directly
Depends on product. Some provide strong consistency (e.g., MongoDB) whereas others offer eventual consistency (e.g., Cassandra)