Relational means other than the tabular form or relations

 Relational databases are databases that rely on tables, columns, rows, or schemas to organize and retrieve data. A NoSQL  originally refers to non-Structured Query Language or  non relational database gives a structure for storing and getting data that is presented in means other than the tabular form or relations likewise used in “relational databases”.Such databases have existed since the late 1960s, but didn’t obtain the  NoSQL  moniker until a surge of popularity in the early twenty-first century, triggered by the needs of Web 2.0 companies such as Facebook, Google, and NoSQL databases are increasingly used in big data and real-time web applications. NoSQL systems are also sometimes called “Not only SQL” to emphasize that they may support SQL-like query languages.Inspirations for this approach include:-Ease of design, simpler horizontal scaling to clusters of machines which is a concern for relational databases and better control over availability. The data structures used by NoSQL databases e.g. key-value, wide column, graph, or document are different from those used by default in relational databases, making some operations faster in NoSQL. The particular suitability of a given NoSQL database depends on the problem it must solve. Sometimes the data structures used by NoSQL databases are also viewed as more flexible than relational database tables.The main reason not to use an SQL database is scalability. The transactional guarantees and the relational model make it almost impossible to scale a database usefully across more than a few machines, especially given the write-heavy workloads generated by modern web applications. An app like Facebook can’t be made to work on a straightforward SQL database, except by massive partitioning and sharding, which requires significant adjustments to the app logic as well. That’s why Facebook developed Cassandra.Types of nosql databases model and their classification with examples:Wide-Column:This type of databases store data in tables with rows and columns similar to RDBMS, but names and formats of columns can vary from row to row across the table. Wide-column databases group columns of related data together.  E.g. Accumulo, Cassandra, Druid, HBase, Vertica.Document:This type of databases typically store self-describing JSON, XML, and BSON documents. E.g. Apache CouchDB, ArangoDB, BaseX, Clusterpoint, Couchbase, Cosmos DB, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDBKey-value: This type of databases emphasize simplicity and are very useful in accelerating an application to support high-speed read and write processing of non-transactional data. e.g. Aerospike, Apache Ignite, ArangoDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, InfinityDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB, SDBM/Flat File dbmGraph: This type of databases uses graph structures to store, map, and query relationships. They provide index-free adjacency, so that adjacent elements are linked together without using an index. E.g. AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, VirtuosoMulti-model: This type of databases leverage some combination of the four types described above and therefore can support a wider range of applications. E.g. Apache Ignite, ArangoDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDBDevelopers require agility, and so there have long been internal struggles between data people and software people. Data people want consistency, they want their data assets safe and reliable. Software developers want agility, they want their projects done quickly and in iterations at least in Agile camps. They would like to have free hands to change the databases, change the schema, do whatever they want with the data. Such situation led in many organizations to developers adopting NoSQL stores just to move faster. Luckily, the early antagonism caused by the disparate adoption of NoSQL systems into the larger Enterprise Information Management structures of many organizations has lessened, and in some cases, that antagonism has become a point of congruence between both sides.NoSQL is no longer viewed as antagonists to relational systems, but as systems with special, unique capabilities. There is a peaceful co-existence forming, but it will still take some time. Today’s applications are expected to run non-stop and must efficiently manage continuously growing amounts of multi structured data in order to do so. This has caused NoSQL to grow from something to a serious consideration for every database, from small shops to the enterprise.