Skip to main content

NoSQL- Document database

1)   What is Document Database?

Built around JSON-like documents, document databases are both natural and flexible for developers to work with. They promise higher developer productivity, and faster evolution with application needs. As a class of non-relational, sometimes called NoSQL database, the document data model has become the most popular alternative to tabular, relational databases.


 2)   What makes document databases different from relational databases?

1. Intuitive Data Model: Faster and Easier for Developers

Documents map to the objects in your code, so they are much more natural to work with. There is no need to decompose data across tables, run expensive JOINs, or integrate a separate ORM layer. Data that is accessed together is stored together, so you have less code to write and your users get higher performance.

2. Flexible Schema: Dynamically Adapt to Change

A document’s schema is dynamic and self-describing, so you don’t need to first pre-define it in the database. Fields can vary from document to document and you modify the structure at any time, avoiding disruptive schema migrations. Some document databases offer JSON Schema so you can optionally enforce rules governing document structures.

3. Universal: JSON Documents are Everywhere

Lightweight, language-independent, and human readable, JSON has become an established standard for data interchange and storage. Documents are a superset of all other data models so you can structure data any way your application needs – rich objects, key-value pairs, tables, geospatial and time-series data, and the nodes and edges of a graph. You can work with documents using a single query language, giving you a consistent development experience however you’ve chosen to model your data.

4. Powerful: Query Data Anyway You Need

An important difference between document databases is the expressivity of the query language and richness of indexing. The MongoDB Query Language is comprehensive and expressive. Ad hoc queries, indexing, and real time aggregations provide powerful ways to access, transform, and analyze your data. With ACID transactions you maintain the same guarantees you’re used to in SQL databases, whether manipulating data in a single document, or across multiple documents living in multiple shards. 

5. Distributed: Resilient and Globally Scalable

Unlike monolithic, scale-up relational databases, document databases are distributed systems at their core. Documents are independent units which makes it easier to distribute them across multiple servers while preserving data locality. Replication with self-healing recovery keeps your applications highly available while giving you the ability to isolate different workloads from one another in a single cluster. Native shading provides elastic and application-transparent horizontal scale-out to accommodate your workload’s growth, along with geographic data distribution for data sovereignty.

 

3)   How much easier are documents to work with than tables?

4) Why not just use JSON in a relational database?

With document databases empowering developers to build faster, most relational databases have added support for JSON. However, simply adding a JSON data type does not bring the benefits of a native document database. Why? Because the relational approach detracts from developer productivity, rather than improve it. These are some of the thing’s developers must deal with.

 Proprietary Extensions

Working with documents means using custom, vendor-specific SQL functions which will not be familiar to most developers, and which don’t work with your favorite SQL tools. Add low-level JDBC/ODBC drivers and ORMs and you face complex development processes resulting in low productivity.

 Primitive Data Handling

Presenting JSON data as simple strings and numbers rather than the rich data types supported by native document databases such as MongoDB makes computing, comparing, and sorting data complex and error prone.

 Poor Data Quality & Rigid Tables

Relational databases offer little to validate the schema of documents, so you have no way to apply quality controls against your JSON data. And you still need to define a schema for your regular tabular data, with all the overhead that comes when you need to alter your tables as your application’s features evolve.

 Low Performance

Most relational databases do not maintain statistics on JSON data, preventing the query planner from optimizing queries against documents, and you from tuning your queries.

 No native scale-out

Traditional relational databases offer no way for you to partition (“shard”) the database across multiple instances to scale as workloads grow. Instead you must implement sharding yourself in the application layer or rely on expensive scale-up systems.

 

Supporting URLs for Practicing:

https://docs.atlas.mongodb.com/getting-started/#atlas-getting-started

https://mongoplayground.net/

Labels:

Comments

Post a Comment

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
Post a Comment
Read more

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/
Post a Comment
Read more

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” }
Post a Comment
Read more