Hey guys, I am Venkat and in this short three-part video series we'll discuss all
the basics you need to get started with mongo DB, a cross-platform non-relational database.
First, let's understand the difference between a relational and a non-relational database.
In a relational database like sql server or oracle, a database is a collection of tables,
that is, it contains one or more tables and it is these tables that store data,
simply put a relational database is a collection of one or more tables. A database table contains
one or more rows, that is it's a collection of rows. A table row contains one or more columns.
in a non-relational database like mongodb for example, we do not have tables, instead we have
collections and documents. A collection as the name implies is a collection of one or more
documents. If you're from a relational database background you can think of a collection as a
table and documents as table rows, so in mongodb a database contains one or more collections,
a collection is made up of one or more documents, and each document is made up of one or more
fields. Now, both in SQL, that is relational and non-relational world we have database at the top,
in sql we have tables and in the non-relational world like mongodb
for example we have collections, table rows in sql world correspond to BSON documents
in mongodb, BSON is Binary JSON. We'll discuss JSON and BSON and the difference between them
in just a bit, a column in the SQL world corresponds to a field in a JSON document,
now it gets a bit easier if we understand these four technical terms in mongodb - Collection,
Document, JSON and BSON, so in a nutshell think of a collection as a table and a document as
a table row. Now, let's switch gears a bit and understand JSON and BSON. At the end of the day,
mongodb is a database and we use it to store data. In a relational database like sql server data is
stored in a table obviously in rows and columns, in mongodb we do not have tables, instead we have
documents, so data in mongodb is stored in BSON documents, BSON is Binary JSON. So, first let's
understand what is JSON? The acronym JSON stands for JavaScript Object Notation. In this example we
have student data. JSON format is text based and both humans and machines can very easily read it,
this is the reason it became a very popular format for storing and exchanging data between
software systems. Data in a JSON document is stored in key value pairs, example "name":"John",
a key value pair consists of a field name in double quotes followed by a colon, followed by
a value, value can be a string, number, boolean or an array. In this example, name field value is
a string, age is a number, graduated is a boolean value, true or false, awards is an array. A field
value in a JSON document can also be another nested JSON document. In this example, address
field value is another json document with its own set of fields and values, so the address is
an embedded json document. There is a one-to-one relationship between student and address. To model
something like this in a relational database we may have two tables - Students stores students
data, Addresses store address data. To relative data we have to join and query both the tables.
In mongo we have the entire data in one document, there is obviously no need for expensive join
operations, "awards" field value is an array, a student may have received zero or more awards,
so there's a one-to-many relationship between Students and Awards, again to model something
like this in a relational database we may have two database tables - Students stores students data,
Awards stores awards data, in mongo we have all the data in one json document. Now, what's the
difference between JSON and BSON. JSON stands for JavaScript Object Notation and BSON stands for
Binary JavaScript Object Notation. Simply put BSON is Binary JSON and it is in this format
mongodb stores data internally on the disk, so in a nutshell BSON is the serialization format used
in mongodb. At this point you might be wondering we already have JSON, why did mongodb invent BSON?
Well, JSON only supports a limited number of basic data types - string, boolean, number, array, also
JSON is a text based format and parsing json text is very slow, we want database engines to be fast,
we don't want text parsing to slow it down, hence mongodb invented BSON, the following
are the three primary differences between JSON and BSON. At this point you might be wondering
should I now learn this new binary BSON format? Well, now as developers we still use JSON format
and mongodb takes care of converting it to BSON and saving it on the disk. In your JSON documents
if required use the additional data types provided by BSON, we don't have to worry about the internal
BSON format, it's all taken care of by mongodb, remember BSON is a binary representation
of JSON and it contains more data types than JSON, so you can think of BSON as a superset of JSON.
Now, let's take a look at a very simple but a real world use case. Let's say we're developing
an application for a training institute and we have a page that displays student names and the
courses they have enrolled in on a web page as you can see right here. To model something like this
in a relational database world like SQL Server or Oracle we typically create three tables.
Students stores the details of students like id and name. Courses stores the course details
like course id and name. StudentCourses, there is a many-to-many relationship between students
and course tables, meaning a student can enroll in multiple courses, that is many courses,
similarly a given course can have multiple students enrolled. So, this is the table
that links students and courses, basically the bridge table for many to many relationship between
students and courses. On the application side, to be able to display this database data we may have
a class that looks like the following. This is a very very simple example here. In the real world
in our application layer we may use object oriented programming concepts like inheritance,
polymorphism etc between classes which makes it even more difficult and a painful exercise to
map our application layer objects to database tables and rows, so the point that I'm trying
to get across is, there is a lot of misalignment between application classes and database tables,
simply put, our application objects are not tables and rows. Now, to fill this gap and misalignment
we may write a custom mapping layer or use ORMs, that is object relational mappers like Entity
Framework for example. As software engineers we want to reduce all this complexity and use of
additional softwares, instead we want a database that is easy to use with our application code.
Now, let's see how the same data may be stored in a non-relational database like mongodb.
As we have already discussed, in mongo we do not have tables and rows, instead we have collections
and documents. You can think of a collection in mongoDB as a table in a relational database,
and a document as a table row. In this example we have one collection, the name of the collection
is StudentCourses. In this collection we have three documents, so just like how
a table is a container for rows, a collection is a container for documents, it is the document
that physically stores data, the data is in BSON format, so the documents are also called
BSON documents. If you're wondering what is BSON? Well, it's Binary JSON, mongodb stores data on
the disk in BSON format, the same students and courses data that we have across three tables in
a relational database can be stored in a single collection in mongo as shown right here, for any
application this data is very easy to work with, no complex joins and mapping layers are required,
our application code will be much cleaner, simpler and easier to maintain. So, does this mean we
cannot define relationships between documents in a non-relational database like mongodb? Well,
we can define relationships between documents in mongodb, but these are usually kept to an absolute
minimum, in most cases we embed json documents inside another document, the obvious benefit of
this approach is, we have all the data we need in one place and there is no need to traverse
multiple related documents, here's the important bit, we can define relationships or references
in mongodb , we can even completely normalize schema in mongodb just like a relational database,
but the question is, if you want to normalize and use a non-relational database like a relational
database, why use a non-relational database? Use a relational database like Sql server
or Oracle, this nicely leads us to another common question we may have. When to use a relational
database like sql server over a non-relational database like mongodb and vice versa? Well,
relational databases are still the best choice if the data is predictable in terms of structure,
size and frequency of access, also if relationships between entities are important
again relational databases are the best choice, normalization in a relational database reduces
the size of the data on disk by limiting duplicate data and anomalies, in a non-relational database
documents are embedded within documents which helps keep data that will be accessed together
in the same place, but if this isn't right for your needs use a relational database,
for example, if you have a very large data set with complex structure and relationships,
embedding might not create clear enough relationships. Finally, relational databases
have been around for a very very long time, which means there is wide support available
from tools to integration with data from other systems. On the other hand, if you want
a flexible schema for the data that is in terms of shape or size or if it needs to be open to change
in the future then a non-relational database is the answer. Non-relational databases have
been designed from the ground up for the cloud which makes them naturally good for horizontal
scaling where lots of small servers can be spun up to handle increased load. Now, what is NoSql?
Lots of people use these two terms NoSql database and non-relational database interchangeably,
a non-relational database like mongodb is more than a NoSql database, so, what does NoSql stand
for? Well, when we hear this term we think NoSql means there is No Sql, this is not true, the term
NoSql stands for Not Only Sql, and it means a non-relational database is a non-tabular database
and stores data differently than relational tables, for example in a relational database
like SQL Server or Oracle, data is stored in tables whereas in a non-relational database like
mongodb data is stored in JSON documents, there are different types of non-relational databases,
Document database, as the name implies data is stored in documents, for example
in json documents, examples of document databases are mongodb and Couchdb. Key value database,
it stores data as a collection of key value pairs in which a key is used as a unique identifier,
both keys and values can be anything ranging from simple objects to complex compound objects,
examples are Dynamodb and Redis. Wide column store, it's similar to a relational database
in the sense it stores data in rows and columns, however the columns are dynamic and each row does
not have to have same columns, examples are HBase and Cassandra, finally, Graph database, it is used
to store and navigate relationships, there's no limit to the kind and number of relationships,
it's heavily used in fraud detection and social networking, it is easy to create relationships
between data entities and quickly query these relationships, for example you can find out who
the friends of friends of a particular person are. Examples are DGraph and OrientDB. Now,
let's focus on the benefits of using a document database, it has easy to use data model,
in a document database like mongodb we do not have tables and rows, instead we have collections and
documents, the data that we typically store across many many relational database tables can be stored
in a single collection, for an application this data is very easy to work with, no complex joins
and mapping layers are required, our application code will be much cleaner, simpler and easier to
maintain, flexible schema is another benefit, JSON documents that actually store data have a flexible
schema which means it's perfectly okay and normal for two documents to have different fields,
in this example we have two documents with student data, both the documents have id and name fields,
in the first document we have graduated boolean field, whereas in the second document
instead of graduated we have a string gender field, so the point is, document schema in mongo
is dynamic and self-describing, every document we save in mongo can be as flat and simple or as
complex as our application requires, mongodb query language, MQL is based on JavaScript
and very easy to learn. When querying data you have a wide range of options, operators,
expressions and filters. Data is very easy to query and you rarely need joins or transactions,
the mongodb query language is a full featured powerful language that allows you to query deep
into documents and even use the aggregation framework to perform complex analytics with
just a few lines, indexing is also supported which means documents can be retrieved quickly,
most relational or sql databases allow only vertical scaling which is also commonly called
scaling up, vertical scaling involves adding more resources like memory, storage etc to the existing
database server, vertical scaling has an upper limit beyond which you cannot just add more CPU,
memory etc, there is also downtime involved, you have to shut the database server down
to add more hardware, mongodb on the other hand supports horizontal scaling which is also commonly
called scaling out, in horizontal scaling data is partitioned and distributed across many servers,
so in simple terms scaling horizontally means adding more servers to the already existing pool
of servers, this means you're not limited to the capacity of a single server, there's no need to
turn off existing servers to add a new server to the pool, so there's no down time as well,
so non-relational databases like mongodb have become very popular. The following is one of
the common questions asked these days in a software engineer interview, have you got
any experience with a non-relational database? What's the difference between a relational and a
non-relational database? Non-relational databases are gaining great traction and they're here
to stay, if you're a software engineer it's invaluable to have a non-relational database
like mongodb in your tool belt. That's it in this video, thank you for listening.