Databases — SQL and NoSQL. Introduction to NoSQL databases with a... | by Anuradha Wickramarachchi | Towards Data Science

SQL came in to play with the research paper “A Relational Model of Data for Large Shared Data Banks” in 1970 by Dr. E. F. Codd. Yes!! that’s the Codd in Boyce-Codd normalization.
NoSQL came into play on late 1990’s. Yet, there has been such databased even before. NoSQL was introduced with the motive of breaking the bottle neck of traditional transactional databases. A common misconception is that NoSQL databases are not relational, which is not quite right. Relationships do exist in data, which would be useless otherwise. Let’s see what changed and how.
CAP theorem tries to demonstrate the properties expected by a NoSQL database. Most of the databases are designed to achieve two of these properties at the cost of another property.
C — ConsistencyThis demonstrates the guarantee on the execution of updates and the availability of the updates as soon as they are acknowledged to the updater. In simpler terms if a database is consistent, updates are available as soon as they are completed, which is not a guarantee in a distributed environment.
A — AvailabilityThis demonstrates the property of a database where it is capable to serve a request. Most of the SQL databases drop queries if the load/execution times are greater. Availability is expected to be very high and response times are expected to be very low in NoSQL databases by elimination of transactional properties that are present in SQL databases.
P — Partition toleranceThe property of databases being able to function with failures among nodes due to network issues. For an example a database may contain several nodes (MongoDB nodes) that work together (By a mechanism such as Mapreduce). The property is preserved if the database as a whole can operate even one or more nodes are unreachable in a distributed environment.
ACID properties are the expected properties in a traditional relational databases such as MySQL, MS SQL or Oracle databases.
A — AtomicityThe property which guarantees atomic operations, either a set of queries can complete as a whole or none does. This is the key feature for transactions.
C — ConsistencyData are available as soon as they are completely inserted or updated.
I — IsolationImplies that, transactions are independent. Therefore data will not be negatively affected by two transactions happening on same set of data.
D — DurabilityCommitted data after a transaction or any other operation is never lost. Either they get inserted or failure is notified (Failed transactions).
NoSQL databases are guaranteed to adhere to two of the CAP properties. Such databases are of several types.
Key-Value Store — Stores in the form of a hash table {Example- Riak, Amazon S3 (Dynamo), Redis}Document-based Store — Stores objects, mostly JSON, which is web friendly or supports ODM (Object Document Mappings). {Example- CouchDB, MongoDB}Column-based Store — Each storage block contains data from only one column {Example- HBase, Cassandra}Graph-based — Graph representation of relationships, mostly used by social networks. {Example- Neo4J}
Key-Value Store — Stores in the form of a hash table {Example- Riak, Amazon S3 (Dynamo), Redis}
Document-based Store — Stores objects, mostly JSON, which is web friendly or supports ODM (Object Document Mappings). {Example- CouchDB, MongoDB}
Column-based Store — Each storage block contains data from only one column {Example- HBase, Cassandra}
Graph-based — Graph representation of relationships, mostly used by social networks. {Example- Neo4J}
MongoDB is one of the widely used document database. It obeys the C and A in the CAP thoerem. MongoDB is heavily used with NodeJS due to its JSON friendly API.
Installation instructions are available at Mongo Official website: https://www.mongodb.com. Let’s consider a few commands using the MongoDB CLI.
Entering the CLI: mongo and press enter. If installation is successful you should see the following output. Usually mongo DB runs on port 27017.
# mongoMongoDB shell version v3.4.5connecting to: mongodb://127.0.0.1:27017MongoDB server version: 3.4.5Server has startup warnings:2017-09-15T11:42:04.673+0000 I STORAGE  [initandlisten]2017-09-15T11:42:04.673+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine2017-09-15T11:42:04.673+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem2017-09-15T11:42:05.313+0000 I CONTROL  [initandlisten]2017-09-15T11:42:05.313+0000 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.2017-09-15T11:42:05.313+0000 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.2017-09-15T11:42:05.313+0000 I CONTROL  [initandlisten]>
Show databases: show dbs
InsertingEnter use mydb and a new database name mydb will be created. Unlike tables in MySQL, Mongo has collections. Documents (JSON) are inserted into such collections. Let’s create the dogs collection and add a dog name Molly with weight 50kg. Since we have selected mydb we can call it as db and perform operations.
db.dogs.insert({name: ‘Molly’, weight:50})
Viewing dataUsing the pretty method formats the output for a more readable format. As you can see mongo add an id name _id as an index to each of the documents.
> db.dogs.find(){ "_id" : ObjectId("59bbce8288b6c364cefd9de6"), "name" : "Molly", "weight" : 50 }> db.dogs.find().pretty(){    "_id" : ObjectId("59bbce8288b6c364cefd9de6"),    "name" : "Molly",    "weight" : 50}>
Updating dataThe command below updates the entry we made and set the name to Tommy.
> db.dogs.update({_id: ObjectId('59bbce8288b6c364cefd9de6')},   {$set: {name:'Tommy'}})
Deleting dataLets delete what we have inserted
> db.dogs.remove({_id:ObjectId('59bbce8288b6c364cefd9de6')})WriteResult({ "nRemoved" : 1 })>
Those are the basic operations of any database, or simply the CRUD operations.
C — CreateR — ReadU — UpdateD — Delete