An introduction to MongoDB

 MONGODB

 

       Introduction

MongoDB is an Open Source, Document Database which provides high performance and scalability along with data modeling and data management of huge sets of data in an enterprise application.  The term ‘NoSQL’ means ‘non-relational’. It means that MongoDB isn’t based on the table-like relational database structure but provides an altogether different mechanism for storage and retrieval of data. This format of storage is called BSON (similar to JSON format). MongoDB is a cross platform database and can be installed across different platforms like Windows, Linux etc.

 

What is Mongo DB?  

Mongo DB is a document-oriented No SQL database used for high volume data storage. Instead of using tables and rows as in the traditional relational databases, Mongo DB makes use of collections and documents. Documents consist of key-value pairs which are the basic unit of data in Mongo DB. Collections contain sets of documents and function which is the equivalent of relational database tables. Mongo DB is a database which came into light around the mid-2000s.

        Discovery of Mongo DB

Mongo DB was founded in 2007 by Dwight Merriman, Eliot Horowitz and Kevin Ryan – the team behind DoubleClick.

At the Internet advertising company DoubleClick (now owned by Google), the team developed and used many custom data stores to work around the shortcomings of existing databases. The business served 400,000 ads per second, but often struggled with both scalability and agility. Frustrated, the team was inspired to create a database that tackled the challenges it faced at DoubleClick.

 Mongo DB Features:

1.  Each database contains collections which in turn contains documents. Each document can be different with a varying number of fields. The size and content of each document can be different from each other.

2.  The document structure is more in line with how developers construct their classes and objects in their respective programming languages. Developers will often say that their classes are not rows and columns but have a clear structure with key-value pairs.

3.  The rows (or documents as called in Mongo DB) doesn’t need to have a schema defined beforehand. Instead, the fields can be created on the fly.

4.  The data model available within Mongo DB allows you to represent hierarchical relationships, to store arrays, and other more complex structures more easily.

     5.  MongoDB is built on a scale-out architecture that has become popular with   

         developers of all kinds for developing scalable applications with evolving                                          

        data schemas.

     6.  As a document database, MongoDB makes it easy for developers to store                          structured or unstructured data. It uses a JSON-like format to store documents. This format directly maps to native objects in most modern programming languages, making it a natural choice for developers, as they don’t need to think about normalizing data. MongoDB can also handle high volume and can scale both vertically or horizontally to accommodate large data loads.

 

         Key Components of Mongo DB Architecture:

Below are a few of the common terms used in Mongo DB

1.    _id - This is a field required in every Mongo DB document. The _id field represents a unique value in the Mongo DB document. The _id field is like the document’s primary key. If you create a new document without any _id field, Mongo DB will automatically create the field. So for example, if we see the example of the above customer table, Mongo DB will add a 24 digit unique identifier to each document in the collection.

2.    Collection - This is a grouping of Mongo DB documents. A collection is the equivalent of a table which is created in any other RDMS such as Oracle or MS SQL. A collection exists within a single database. As seen from the introduction collections don’t enforce any sort of structure.

3.    Cursor - This is a pointer to the result set of a query. Clients can iterate through a cursor to retrieve results.

4.    Database - This is a container for collections like in RDMS wherein it is a container for tables. Each database gets its own set of files on the file system. A Mongo DB server can store multiple databases.

5.    Document - A record in a Mongo DB collection is basically called a document. The document, in turn, will consist of field name and values.

6.    Field - A name-value pair in a document. A document has zero or more fields. Fields are analogous to columns in relational databases.

7.    JSON - This is known as JavaScript Object Notation. This is a human-readable, plain text format for expressing structured data. JSON is currently supported in many programming languages.

 

  Why Use Mongo DB?

Below are the few of the reasons as to why one should start using Mongo DB:

1. Document-oriented

Since Mongo DB is a No SQL type database, instead of having data in a relational type format, it stores the data in documents. This makes Mongo DB very flexible and adaptable to real business world situation and requirements.

2. Ad hoc queries

Mongo DB supports searching by field, range queries, and regular expression searches. Queries can be made to return specific fields within documents.

 3. Indexing

Indexes can be created to improve the performance of searches within Mongo DB. Any field in a Mongo DB document can be indexed.

4. Replication

Mongo DB can provide high availability with replica sets. A replica set consists of two or more mongo DB instances. Each replica set member may act in the role of the primary or secondary replica at any time. The primary replica is the main server which interacts with the client and performs all the read/write operations. The Secondary replicas maintain a copy of the data of the primary using built-in replication. When a primary replica fails, the replica set automatically switches over to the secondary and then it becomes the primary server.

5. Load balancing 

Mongo DB uses the concept of shading to scale horizontally by splitting data across multiple Mongo DB instances. Mongo DB can run over multiple servers, balancing the load and/or duplicating data to keep the system up and running in case of hardware failure.

 

MONGODB ATLAS

 Database-as-a-Service (DBaaS) is a service that allows you to set up, deploy, and scale a database without worrying about on-premise physical hardware, software updates, and the details of configuring for performance. With DBaaS, a cloud provider does all that for you—and gets you up and running right away.

MongoDb Atlas is a fully-managed cloud database that handles all the complexity of deploying, managing, and healing your deployments on the cloud service provider of your choice (AWS , Azure, and GCP). MongoDB Atlas is the best way to deploy, run, and scale MongoDB in the cloud. With Atlas, you’ll have a MongoDB database running with just a few clicks, and in just a few minutes. 

 Mongo DB vs PostgreSQL

MongoDB	PostgreSQL
Schema-free	SQL-based but supports various NoSQL features
Document database	Relational database
Uses BSON	Uses SQL
Distributed architecture	Monolithic architecture
Potential for ACID compliance	ACID-compliant
Uses collections	Uses tables
Uses documents to obtain data	Uses rows to obtain data
Does not support foreign key constraints	Supports foreign key constraints
Uses the aggregation pipeline for running queries	Uses GROUP_BY
Redundant replica sets	2-safe replication
Uses indexes	Uses joins

 Mongo DB vs SQL

MongoDB	MYSQL
MongoDB represents data as JSON documents.	MySQL represents data in tables and rows.
In MongoDB, you don’t need to define the schema. Instead, you just drop in documents don’t even need to have the same fields.	MySQL requires you to define your tables and columns before you can store anything, and every row in a table must have the same columns.
MongoDB has a pre-defined structure that can be defined and adhered to, but also, if you need different documents in a collection, it can have different structures.	MySQL uses Structured Query Language (SQL) for database access. You can’t change the schema.
Supported languages are C++, C	Supported languages are C++, C and JavaScript
Ongoing development is done by MongoDB, Inc.	Constant development is done by the Oracle Corporation.
MongoDB supports built-in replication, sharding, and auto-elections.	MySQL supports master-slave replication and master replication.
If an index is not found, every document within a collection must be scanned to select the documents which offer a match to the query statement.	If an index is not defined, then the database engine needs to scan the complete table to find all relevant rows.
GPL v2/ Commercial license available OD	GNU AGPL v3.0/ Commercial licenses available OD
If most of your services are cloud based MongoDB is the best suited for you.	If data security is your priority then MYSQL is the best option for you.
MongoDB places no restrictions on schema design.	MySQL requires you to define your tables and columns before you can store anything. Every row in a table must have the same columns.
MongoDB uses JavaScript as query language.	MySQL uses the Structured Query Language (SQL).
MongoDB doesn’t support JOIN.	MySQL supports JOIN operations.
It has the ability to handle large unstructured data	MySQL is quite slow in comparison to MongoDB while dealing with large databases.
Real-time analytics, content management, internet of things, mobile apps	Structured data with clear schema
No schema definition required so lesser risk of attack due to design	Risk of SQL injection attacks
An ideal choice if you have unstructured and/or structured data with the potential for rapid growth.	A great choice if you have structured data and need a traditional relational database.

Real Life Application of Mongo DB

FOURSQUARE: is a location-based social network which has grown rapidly since its inception in 2009, requiring efficient ways to scale with limited engineering resources. As its user profile and activity stream data increased, foursquare made the strategic decision to migrate storage of venues and check-ins to Mongo DB as a long-term scalable solution to the company's continued expansion.

Originally, the foursquare application relied on a single relational database. As the company experienced rapid growth, they split the data to two nodes: one for check-ins (the biggest data set) and one for everything else. However, it was clear that in time, check-ins alone would increase beyond what a single machine could handle. Mongo DB not only solved the initial problem, but also provided the tools for agile development.

Foursquare can now take advantage of Mongo DB's built-in auto-shading. Mongo DB’s auto-shading partitions the database, allowing foursquare to scale writes and spin up new nodes as their application grows. Instead of writing its own shading layer, foursquare can rely on Mongo DB’s automated scaling infrastructure, enabling engineers to focus on building their application.

Mongo DB has allowed foursquare it to dramatically simplify its data model. For instance, rather than storing tags (“has Wi-Fi”, “great for dates”, “hotspot”, etc.) in a separate table, in Mongo DB tags are embedded directly into the document representing a venue. This is both more efficient at run-time and easier for engineers to understand and manipulate.

CRAIGSLIST: is a popular classifieds and job posting community which serves 570 cities in 50 countries. With 1.5 million new classified ads posted every day, Craigslist must archive billions of records in many different formats, and must be able to query and report on these archives at runtime. Historically, Craigslist stored its information in a MySQL cluster but the lack of flexibility and management costs became barriers for continued use. In 2011, Craigslist migrated over two billion documents to Mongo DB for its scalability and flexible schema. For much of the history of Craigslist, MySQL was the only option for data storage, including the archive. 

The original Craigslist archive application took the existing live database data and copied it to the archive system. But using a relational database system limited flexibility and caused lengthy delays because changes to the live database schema needed to be propagated to the archive system. When making changes to billions of rows in their MySQL cluster, Craigslist could not move data to the archive. Archive-ready data would pile up in the production database; performance on the live database deteriorated. To prevent further impediments to the company's growth and ability to serve its customers, the team began looking for alternative explanations. After evaluating several No SQL options, Craigslist settled upon Mongo DB. One compelling reason is that Mongo DB boasts built-in scalability. Each post and its metadata can be stored as a single document. As the schema changes on the live database, Mongo DB can accommodate these changes without costly schema migrations. In addition, Mongo DB's support for auto-shading and high availability eased operational pain points for Craigslist. Mongo DB enabled Craigslist to scale horizontally across commodity hardware without having to write and maintain complex, custom shading code. Using auto-shading, Craigslist's initial Mongo DB deployment was designed to hold over 5 billion documents and 10TB of data. Mongo DB concepts and features are similar, in many respects, to relational databases so Craigslist’s developers found the transition seamless.

 Conclusion

         MongoDB is a popular NoSQL database solution that suits modern development requirements. It is recommended to be used while creating internet and business application that need a quick evolution and scalability. The agile methodologies of MongoDB provide scalability to all kinds of developers around the globe.

 

Authored By:-

Abhishek Dighekar

Haripriya Arya

Abhinav Singh

Atharv Bagade

Chetan Bagul