Skip to main content

All about NoSQL

1)   What is NoSql?

Ans: It is a non-relational database; some say the term “NoSQL” stands for “non-SQL” while others say it stands for “not only SQL.” Either way, most agree that NoSQL databases are databases that store data in a format other than relational tables. NoSQL databases are purpose built for specific data models and have flexible schemas for building modern applications. NoSQL databases are widely recognized for their ease of development, functionality, and performance at scale.

 

2)   How Does a NoSQL (nonrelational) Database Work?

Ans: NoSQL databases use a variety of data models for accessing and managing data. These types of databases are optimized specifically for applications that require large data volume, low latency, and flexible data models, which are achieved by relaxing some of the data consistency restrictions of other databases.

 

Consider the example of modeling the schema for a simple book database:

 

In a relational database, a book record is often dissembled (or “normalized”) and stored in separate tables, and relationships are defined by primary and foreign key constraints. In this example, the Books table has columns for ISBN, Book Title, and Edition Number, the Authors table has columns for AuthorID and Author Name, and finally the Author-ISBN table has columns for AuthorID and ISBN. The relational model is designed to enable the database to enforce referential integrity between tables in the database, normalized to reduce the redundancy, and generally optimized for storage.

In a NoSQL database, a book record is usually stored as a JSON document. For each book, the item, ISBN, Book Title, Edition Number, Author Name, and AuthorID are stored as attributes in a single document. In this model, data is optimized for intuitive development and horizontal scalability.

 

3)   Why should you use a NoSQL database?

Ans: NoSQL databases are a great fit for many modern applications such as mobile, web, and gaming that require flexible, scalable, high-performance, and highly functional databases to provide great user experiences.

 

-          Flexibility: NoSQL databases generally provide flexible schemas that enable faster and more iterative development. The flexible data model makes NoSQL databases ideal for semi-structured and unstructured data.

-          Scalability: NoSQL databases are generally designed to scale out by using distributed clusters of hardware instead of scaling up by adding expensive and robust servers. Some cloud providers handle these operations behind-the-scenes as a fully managed service.

-          High-performance: NoSQL database are optimized for specific data models and access patterns that enable higher performance than trying to accomplish similar functionality with relational databases.

-          Highly functional: NoSQL databases provide highly functional APIs and data types that are purpose built for each of their respective data models.

4)   Types of NoSQL Databases?

Ans: Over time, four major types of NoSQL databases emerged: document databases, key-value databases, wide-column stores, and graph databases. Let’s examine each type.

 

-          Document databases store data in documents like JSON (JavaScript Object Notation) objects. Each document contains pairs of fields and values. The values can typically be a variety of types including things like strings, numbers, Booleans, arrays, or objects, and their structures typically align with objects developers are working with in code. Because of their variety of field value types and powerful query languages, document databases are great for a wide variety of use cases and can be used as a general-purpose database. They can horizontally scale-out to accommodate large data volumes. MongoDB is consistently ranked as the world’s most popular NoSQL database according to DB-engines and is an example of a document database.

 

-          Key-value databases are a simpler type of database where each item contains keys and values. A value can typically only be retrieved by referencing its key, so learning how to query for a specific key-value pair is typically simple. Key-value databases are great for use cases where you need to store large amounts of data, but you don’t need to perform complex queries to retrieve it. Common use cases include storing user preferences or caching. Redis and DynamoDB are popular key-value databases.

 

-          Wide-column stores store data in tables, rows, and dynamic columns. Wide-column stores provide a lot of flexibility over relational databases because each row is not required to have the same columns. Many consider wide-column stores to be two-dimensional key-value databases. Wide-column stores are great for when you need to store large amounts of data and you can predict what your query patterns will be. Wide-column stores are commonly used for storing Internet of Things data and user profile data. Cassandra and HBase are two of the most popular wide-column stores.

 

-         Graph databases store data in nodes and edges. Nodes typically store information about people, places, and things while edges store information about the relationships between the nodes. Graph databases excel in use cases where you need to traverse relationships to look for patterns such as social networks, fraud detection, and recommendation engines. Neo4j and Janus Graph are examples of graph databases.

 

5)   SQL (relational) vs. NoSQL (nonrelational) databases

Ans: For decades, the predominant data model that was used for application development was the relational data model used by relational databases such as Oracle, DB2, SQL Server, MySQL, and PostgreSQL. It wasn’t until the mid to late 2000s that other data models began to gain significant adoption and usage. To differentiate and categorize these new classes of databases and data models, the term “NoSQL” was coined. Often the term “NoSQL” is used interchangeably with “nonrelational.”

 

Though there are many types of NoSQL databases with varying features, the following table shows some of the differences between SQL and NoSQL databases.

 

 

Relational databases

NoSQL databases

Optimal workloads

Relational databases are designed for transactional and strongly consistent online transaction processing (OLTP) applications and are good for online analytical processing (OLAP).

NoSQL databases are designed for a number of data access patterns that include low-latency applications. NoSQL search databases are designed for analytics over semi-structured data.

Data model

The relational model normalizes data into tables that are composed of rows and columns. A schema strictly defines the tables, rows, columns, indexes, relationships between tables, and other database elements. The database enforces the referential integrity in relationships between tables.

NoSQL databases provide a variety of data models such as key-value, document, and graph, which are optimized for performance and scale.

ACID properties

Relational databases provide atomicity, consistency, isolation, and durability (ACID) properties:

 

·         Atomicity requires a transaction to execute completely or not at all.

·         Consistency requires that when a transaction has been committed, the data must conform to the database schema.

·         Isolation requires that concurrent transactions execute separately from each other.

·         Durability requires the ability to recover from an unexpected system failure or power outage to the last known state.

NoSQL databases often make tradeoffs by relaxing some of the ACID properties of relational databases for a more flexible data model that can scale horizontally. This makes NoSQL databases an excellent choice for high throughput, low-latency use cases that need to scale horizontally beyond the limitations of a single instance.

Performance


Performance is generally dependent on the disk subsystem. The optimization of queries, indexes, and table structure is often required to achieve peak performance

 

Performance is generally a function of the underlying hardware cluster size, network latency, and the calling application.

Scale

Relational databases typically scale up by increasing the compute capabilities of the hardware or scale-out by adding replicas for read-only workloads.

NoSQL databases typically are partitionable because access patterns are able to scale out by using distributed architecture to increase throughput that provides consistent performance at near boundless scale.

APIs

Requests to store and retrieve data are communicated using queries that conform to a structured query language (SQL). These queries are parsed and executed by the relational database.

Object-based APIs allow app developers to easily store and retrieve data structures. Partition keys let apps look up key-value pairs, column sets, or semi structured documents that contain serialized app objects and attributes.

 

6)   SQL vs. NoSQL Terminology

The following table compares terminology used by select NoSQL databases with terminology used by SQL databases.

 

SQL

MongoDB

DynamoDB

Cassandra

Couchbase

Table

Collection

Table

Table

Data bucket

Row

Document

Item

Row

Document

Column

Field

Attribute

Column

Field

Primary key

ObjectId

Primary key

Primary key

Document ID

Index

Index

Secondary index

Index

Index

View

View

Global secondary index

Materialized view

View

Nested table or object

Embedded document

Map

Map

Map

Array

Array

List

List

List

Comments

Popular posts from this blog

SQL Real Time Interview Questions with solutions

SQL_Query : In this MySQL challenge, your query should return the names of the people who are reported to (excluding null values), the number of members that report to them, and the average age of those members as an integer. The rows should be ordered by the names in alphabetical order. Your output should look like the  following table . Solution : SELECT  ReportsTo ,   count ( ReportsTo )   as  Members ,   round ( avg ( Age ),   0 )   as   'Average Age'     FROM  maintable_MS9H0 Where  ReportsTo  is   not   null Group   by  ReportsTo order   by  ReportsTo or SELECT  ReportsTo , COUNT ( FirstName )   as  Members , ROUND ( AVG ( Age ))   as   "Average Age"   FROM  maintable_MS9H0  WHERE  ReportsTo  IS   NOT   NULL   GROUP   BY  ReportsTo SQL_Query: In this MySQL challenge, the table provided shows all new users signing up on a specific date in the format YYYY-MM-DD. Your query should output the change from one month to the next. Because the f

Defect Triaging and Priority vs Severity

 I fount the following sites explained clearly about defect triaging and felt worth to share it my blog to help others.  This question was been asked in many interviews as well "What is defect triaging? And how do you handle it?". Defect Triaging Meeting:  http://www.testingdiaries.com/defect-triage-meeting/#:~:text=Defect%20Triage%20Meetings%20are%20project,are%20defined%20for%20the%20bugs. Defect Triage:  https://www.guru99.com/bug-defect-triage.html#:~:text=Defect%20triage%20is%20a%20process,and%20priority%20of%20new%20defects. Priority Vs Severity:  https://www.guru99.com/defect-severity-in-software-testing.html https://www.softwaretestinghelp.com/how-to-set-defect-priority-and-severity-with-defect-triage-process/

NoSQL Document Database Queries

  -           To check the current database list cmd> show dbs; -           To drop database cmd> db.dropdatabase( ); -           To create collection cmd> db.createCollection(“collection name”); or Use <collection name> -           To insert a document into the collection cmd> db.collectionname.insert([{}]); //insert many documents or one document           db.collectionname.insertOne({}); //inserts one document           db.collectionname.insertMany([{},{}]); //insert many documents -           To Print data in Json format cmd> db.collectionname.find( ).forEach(printjson); -           Basic Find command return entire collection data cmd> db.collectionname.find({} ) -         Search for a specific record and output should be in json format cmd> db.collectionname.find({“fieldname”: value}).forEach(printjson)   output will be: { “id”: ObjectId(“5b75cb657cb6057d416abef67”), “employeeid”:1, “emloyeename”: ”User” }