NoSQL DB

Introduction to NoSQL Cloud Database Services

A NoSQL Cloud Database Services is a database that provides a means that helps to store,- and retrieve a NoSQL database. The Term non-relational/non-SQL is initially referred to as NoSQL. Big data and Web applications are some of its applications that use NoSQL databases in real-time and their utilization boost with time. Sometimes, NoSQL databases are referred to as ‘Not only SQL’ because query languages related to SQL are also supported. Better command over accessibility, less difficult level scaling to bunches of devices, and design simplicity are included in a NoSQL database.

Types of NoSQL Databases:

·        Column-Based

·        Key-value store

·        Graph Databases

·        Document Based

Understanding Documents

Document databases are used for storing semi-structured data as a document—rather than normalizing data across multiple tables, each with a unique and fixed structure, as in a relational database. Documents stored in a document database use nested key-value pairs to provide the document's structure or schema. However, different types of documents can be stored in the same document database, thus meeting the requirement for processing similar data that are in different formats. For example, because each document is self-describing, the JSON-encoded documents for an online store that are described in the topic Example Documents in a Document Database can be stored in the same document database.

 

SQL vs. Nonrelational Terminology

The following table compares the terminology used by document databases (MongoDB) with the terminology used by SQL databases.

Simple Document

All documents in a document database are self-describing. This documentation uses JSON-like formatted documents, although you can use other means of encoding.

A simple document has one or more fields that are all at the same level within the document. In the following example, the fields SSN, LName, FName, DOB, Street, City, State-Province, Postal Code, and Country are all siblings within the document.

{

  "SSN": "123-45-6789",

  "LName": "Rivera",

  "FName": "Martha",

  "DOB": "1992-11-16",

  "Street": "125 Main St.",

  "City": "Anytown",

  "State-Province": "WA",

  "Postal Code": "98117",

  "Country": "USA"

}

When information is organized in a simple document, each field is managed individually. To retrieve the address, you must retrieve Street, City, State-Province, Postal Code, and Country as individual data items.

Embedded Documents

A complex document organizes its data by creating embedded documents within the document. Embedded documents help manage data in groupings and as individual data items, whichever is more efficient in a given case. Using the preceding example, you could embed an Address document in the main document. Doing this results in the following document structure:

{

  "SSN[PS2] ": "123-45-6789",

  "LName": "Rivera",

  "FName": "Martha",

  "DOB": "1992-11-16",

  "Address":

  {

      "Street": "125 Main St.",

      "City": "Anytown",

      "State-Province": "WA",

      "PostalCode": "98117",

      "Country": "USA"

  }

}

You can now access the data in the document as individual fields ( "SSN": ), as an embedded document ( "Address": ),or as a member of an embedded document ( "Address":{"Street":} ).

 

Understanding Normalization in a Document Database

Document databases are not normalized; data found in one document can be repeated in another document. Further, some data discrepancies can exist between documents. For example, consider the scenario in which you purchase at an online store, and all the details of your purchases are stored in a single document. The document might look something like the following JSON document:

{

   "DateTime[PS3] ": "2018-08-15T12:13:10Z",

   "LName" : "Santos",

   "FName" : "Paul",

   "Cart" : [

       {

           "ItemId" : "9876543210123",

           "Description" : "Understanding DocumentDatabases",

           "Price" : "29.95"

       },

       {

           "ItemId" : "0123456789012",

           "Description" : "Programming Today",

           "Issue": {

              "Volume": "14",

              "Number": "09"

          },

           "Price" : "8.95"

       },

       {

           "ItemId": "234567890-K",

           "Description": "Gel Pen (black)",

           "Price": "2.49"

       }

   ],

   "PaymentMethod" :

   {

       "Issuer" : "MasterCard",

       "Number" : "1234-5678-9012-3456"

   },

   "ShopperId" : "1234567890"

}

 

All this information is stored as a document in a transactioncollection. Later, you realize that you forgot to purchase one item. So, youagain log on to the same store and make another purchase, which is also storedas another document in the transaction collection.

{

   "DateTime": "2018-08-15T14[PS4] :49:00Z",

   "LName" : "Santos",

   "FName" : "Paul",

   "Cart" : [

       {

           "ItemId" : "2109876543210",

           "Description" : "Document Databases for Fun andProfit",

           "Price" : "45.95"

       }

   ],

   "PaymentMethod" :

   {

       "Issuer" : "Visa",

       "Number" : "0987-6543-2109-8765"

   },

   "ShopperId" : "1234567890"

}

Notice the redundancy between these two documents—your name and shopper ID (and, if you used the same credit card, your credit card in formation). But that's okay because storage is inexpensive, and each document completely records a single transaction that can be retrieved quickly with a simple key-value query that requires no joins.

There is also an apparent discrepancy between the two documents—your credit card information. This is only an apparent discrepancy because it is likely that you used a different credit card for each purchase. Each document is accurate for the transaction that it documents.

 

Why Choose NoSQL?

Google, Facebook, Amazon, and LinkedIn are a few of the top internet companies that originally use the NoSQL database for overcoming the downside of the Relational Database Management System (RDBMS). A relational Database Management System isn’t dependably the best answer for all circumstance since data handling necessities develop dramatically. A Dynamic method and a better cloud-friendly environment are provided by NoSQL for processing unstructured data.

Difference Between NoSQL Databases and SQL Databases

·        NoSQL database schema is flexible while SQL database schema is rigid.

·        In NoSQL databases, queries are more immediate than in SQL databases.

·        NoSQL databases are non-relational while SQL databases are relational.

·        NoSQL Examples – Hbase, Bigtable.

·        SQL Examples – Sybase, Access, Oracle, and Mysql.