I everyone welcome back.
So we're going to be starting our Mungo at the Tauriel and we're going to be discussing all types of
features and tools that we can use in the Mongo.
DP So let's get started.
So what is Mongo D-B.
So mobility reads a cross-platform document oriented database.
Right so if you remember we saw that a database is just somewhere that you can store data for for for
a long term period.
So if you're a member of the API examples the database is just something that we can put data in for
a very long time and usually has records.
And the one that has records is usually called RDBMS gate or sometimes it has other names but you know
sometimes it's called Arjuna's.
So it's a data so Mongar the left for document oriented database that provides high performance high
availability and easy scalability.
I mean would you be a works on a concept of collections and documents and read discuss in a further
few slides.
What is a collection What is a document.
And we just want to make also some analogies if you're familiar with the normal RDM mast and we're going
to see some analogies between collections and documents and that and so a database as we said is a physical
container for collections where each database gets its own set of files of the file system.
A single Mongo db server typically has multiple databases so if you think about a longer server you
can draw a big box and then call this one a mongo D-B server.
And usually this server might have different databases.
I have the database one and database do.
And then inside of each of these databases if I if I zoom in over here if I zoom in on this area over
here then this oh this is not very zoomed in but if I if I try to zoom in on this database then it's
made up of two things.
It's made of collections and it's made of documents.
As you said and we're going to discuss what each of these are in a few minutes.
OK.
Now a collection is a group of Mongo documents and it's equivalent of an RDBMS table.
So that collection exists within a single table and within a single database of collections don't enforce
the schema and documents within a collection can have different fields.
Typically all documents in a collection are of similar or related purpose or this this me.
So we said that we have a mongo server.
Right.
OK so let's draw the bigger picture.
We have a mango D-B server and inside of that let's say we have only one database.
But usually you can have more than one.
So we have a bunch of databases and then inside this database we might have a bunch of collections so
collection one collection to and inside of these collections we might have a bunch of documents so document
one document to document three document four.
And similarly in the second collection we might also have a bunch of different collections so we have
documents excuse me to document one document two documents three in document four.
So this is the big picture so election is just a group of Mago the documents and it's equivalent of
an RDBMS stable.
And we'll see.
We'll discuss this and even more details in a few slides.
So a collection exists within a single database and the collections do not enforce this schema.
So in the normal case when you have that RDBMS table you usually have some sort of schema.
So you say OK if I have a table in this database the first the first one here is going to be the ID.
The second one is going to be something right.
The third one is going to be something else.
And the fourth line is going to be something else.
I usually have a specified schema where where all the documents inside or all the rows are instead in
this table must satisfy must have these properties right.
Or else you're doing something wrong in the design of the table but in the case of Mongo NDB the really
collections are not in force schema.
CG even has some some documents here or rows which have an ID and then date of birth for example and
then other documents which don't have date of birth but have for example gender.
Right.
So you can have documents that has some properties some of these Robert Fields what we call fields some
fields and not other fields and it's fine to be in the same collection.
So this is not the case for me the RDBMS tables but this is what it since it enforces schemas right.
The whole idea of sequel's is key.
Right.
So.
So in the case of collections you don't have to enforce any schema and the documents with it within
a collection can have different fields right.
And so typically all documents in a collection are similar or related.
So even though they might not share all the fields but they have to relate to or be very similar to
the same purpose right.
They have to really be related or similar to the same purpose.
OK.
OK so what is a document so I document is a set of key value pairs.
And really whenever you're create this word document here think of adjacent file and you're going to
see why.
Why I mean that in a few seconds.
But whenever you see a document just instantly think about Jason files.
So a document is a set of key value pairs and the documents have dynamic schema.
OK so dynamic schema means that documents in the same collection do not need to have the same set of
fields or structure and common fields in a collection documents may hold different types of data.
So an example of a document is it starts with a curly brackets and then it has a key value pair so I'm
going to say key one and then pair with a value so value 1 and then comma.
So if you notice this is a very very similar to what it what to what we discussed in the song when we
were discussing what Jason is this is very similar to Jason.
In fact a document has a very very similar syntax to JCA and this is why we're using it in this in these
projects because most of the times when we're dealing with the web where we're really sending and receiving
lots of Jasons so it will be very very convenient if I can just put or dump this J-Zone into my Mongo
D-B as a document and then retrieve it whenever I want to retrieve it later.
So that's that's that's that's the main idea why we're using longer the B because it's very easy to
just put some files into it or documents will save files.
From now on.
So put Jason documents inside of it and retrieve Jaison right away from it.
So that's the motivation of what a document does.
OK so let's discuss now the relation to a normal database so you might be familiar with normal.
If you've ever played with access for Microsoft Access for example you might be familiar with the normal
database the normal concept of a database.
And then this database usually has a bunch of tables writes a table one table to say you have only two
tables and then each table has a bunch of rows right where each row is is a new entry.
So each of these tables have a neuro and then each column represents a different field.
So for example this is name right.
And then this is date of birth and so on.
And then here we might have different write different names.
So you also get in if you're familiar with normal databases you might be familiar with table joined
and primary keys.
So in the case of Mongo D-B this is very different.
So for that database they're exactly the same right you have databases in both of them.
Right.
Cause they're just data Mieses but instead of having tables you have a collection right.
So the collection that is is a group of documents right.
So we know that a table is a group of rows.
So a collection is a group of documents.
Hopefully that makes a good analogy between the two.
So you can just think of it you can rename the two if you may if you want to help you understand it
in another way.
Now the columns are called fields so the columns in our RDBMS is actually called the field in Mogo to
the beat and table joins are actually called embedded documents.
And we're going to see some examples of these embedded documents and how we can queery them and all
that stuff.
So final thing is the primary key the primary key in a table.
If you're a member in the normal database the primary key is just one of the fields.
Usually it's the first one so primary key I'll just name it P.K. and then the primary key is a unique
key to each record.
So for example you might the easiest type of prime rate is just to use numbers right.
So the first drill would have a unique number of what the second row and having that unique number have
to write a primary key or two.
So these numbers are unique for each record.
So you can think about it as a customer ID right.
You can't have two customers.
Right so you can have customer one customer to one customer id one to three for both of them right.
Because they're not the same customers.
So a primary care is just basically something unique to this record that nobody no other record can
have.
Right.
So you can reference this record directly using this primary key over here.
So in the case of RDBMS but in the case of Mangione we have a field right.
We have a key called ID underscore ID right.
Sharen like this and this is exactly the primary key and it's automatically given by Mongo D-B.
Now you can specify it you can still longer to be had for this document over here give it this idea
for example 1 2 3.
Not exactly 1 2 3.
There is a specific format.
You can tell mongered Eby But if you don't tell it then it automatically gets a very unique ID that
no other record or in the case of mongered need be no other document might have the same ID.
So each document if you you may say has a different ID ID and you can't have two documents with the
same ID.
So really this idea is there is a big clear now let's see an example of a document.
So here's an example of a document we have curly brackets first and then the first is the first one
is the ID.
Right.
This is the one we discussed.
And then this is usually just a unique description off of this object overview of this document over
here.
And no other document might have the same ID as this one.
Now you see we already said that in documents we get to have key value peers.
And so this is the case here.
So we have a username is what do 3 x y Zed contact is a phone and then inside of contacts we can put
another document right.
So we call these embedded Sugg documents and inside this.
So the value the value of the contact key is actually another document which has phone and e-mail.
So no one is watching 3 4 5 6 7 8 9 0.
And email is x y Zed and exampled outcome so this over your if I if I can highlight it this area over
here this whole thing that I just highlighted is actually a document.
So it's called the embedded some document because it's inside another document.
So if you remember this is very similar to JS onsides when we discuss Jaison files we said we can embed
adjacent file inside adjacent sizes so we can have X and then inside of it another Jason's right.
So this is exactly the same idea and we call it in Mongo DBI and bits of documents.
Now here's another embedded document we have access and then level 5 and group depth.
So this year again this year.
And don't forget of course the comma here that separates the elements comma here and comma here too.
Just like Jason and that is so in Access.
This object here is an embedded sub document to the key axis.
Right.
So we can describe this document as a document with this ID and that has to embedded some documents
that correspond to the contact key and the access key.
Now it's worth ENTRAR it's worth to talk a bit about the ID field since it's not really discussed a
lot later but it's it's one of the most important things about mongered be in and why it's unique.
So these are 12 byte hexadecimal number which assures the uniqueness of every document as we see it.
And so you could provide either you while inserting the document if you don't provide the.
If you don't provide that the mongered DV provides a unique ID for every document.
So you're allowed to give your own ID right.
On the condition that it hasn't been used in any other document.
But if you if you don't get it right if you just create a new document and you don't provide an ID then
mongered automatically assigns you a unique ID for every single document.
Now the ID field is made up of 12 bytes.
The first four bytes is for the current time stamp.
So for example let's say you created this object at time 12 25 43 then this this freris for Bies would
have the current time stamp at which you created this option right and with a date and and so on.
So it would have the current step then the next three bytes will be for the machine ID.
So what machine created this document.
And then the next to buy a before the process idea of the Mongo DB server and then the last three bytes
are just simple incremental values right.
So you take all of these and you merge them together and you get your ID field.
Now we also need to discuss a few other things like the Mongo D-B versus relational databases.
So any relational database has a typical schema design that shows a number of tables and the relationships
between these tables while in Mongo D-B there is no concept of relationship.
So this is a very very very important in normal databases you might have for example two tables for
example customer and product sold.
Right.
So you might have two have them products sold and so customers you would have a primary key let's say
just an integer.
So customers want custom into custom custom before.
And so for example customer 1.
Let's say he his name is something right.
And his last name is something.
And so on.
So these are all fields.
And so in the product.
So a table I might have for example a primary key for products right.
For example this product and then pre-Chase or.
Or the person who bought it as another field.
And then this would point to some customer who bought as the prime rate of some customers for example.
Customer 3 bought the first product.
So we can point from here and there's a relationship between this table over here this product old and
the customer and there's a relationship between these two tables.
This is unusual to databases relational databases but in here there is no concept of relationships.
So if you're wanting corporate relationships you have to have to use subduct some documents.
As we saw in a previous life.
So in here for example then this is showing you can have this as a second table and treat and then this
is showing that you're associating this key was this entry over here.
Right.
So so so this is a very important distinction between Mungo IDB and relational database.
There is no idea of relationship and Mongo D-B.
Now what are the advantages of longer IDB over just RDBMS in general.
And so there are a few a few advantages.
The first is of course it's keyless schema less so Mongul Gibbie's a document database in which one
collection holds different documents and the number of fields content and size of the document can differ
from one document to another.
Now this is not the same in usual in normal tables as we discussed because tables are already fixed
right.
They have to have all these fields over here.
Now some of them might be now.
Right.
If you if you're familiar with with take with the regular databases some of them might be no but that
doesn't change the fact that you have to have all these fields in any given record.
But this is not the same.
So this is what we call a schema.
Right.
But this is not the same thing in the case of NDB you can have a collection or which is analogous to
a table and it can have documents with a different number of fields content size.
And you know lots of different stuff.
And so also the structure of a single object is clear and there is no complex joins.
And it has a deep query ability so much be supports dynamic queries on documents using a document based
query language that's nearly as powerful as as fuel.
So this is very strong.
The queen you would think that what you know the schemas here are made to make searches faster but in
fact Magdi me even though it's schema less it's actually very very fast in queering.
In fact it's as almost as fast as Eski well.
So this is you know big Also that tuning so you can tune the longer NDB a lot.
And it's easy to scale out mongered Phoebes among LADEE is super super easy to scale up.
So let's say you're you're servicing only a bunch of customers today.
Well in the next the next few if your customers for example suddenly multiply by 100 right so you go
viral for example.
The longer be super super easy to scale.
Right.
So it supports scaling very easily.
And so conversion and mapping of application objects to database objects is not needed and uses internal
memory for storing the windowed working set enabling faster access of data.
So this is a very important point to.
Now why should we use Mago D-B Zo.
So first of all it's a document oriented storage so the data is stored in the form of a Jason style
document and the index attributes.
There's an index on any attribute you can add replication and high availability so it doesn't fill all
that all too much.
You can have auto shorting and we'll talk about that later.
We have reached queries you can you can really formulate some very very complex queries.
There is fast in place updates.
So this is also fast.
Oops let's go back.
So very fast updates.
And then also professional support by Mongo D-B that is almost 24/7.
So this is pretty cool.
Now let's see freek'n OK here we go.
So where do you use mangosteen.
So when should we use with me instead of a sequel for example a sequel database.
So in the case of big data this is automatically you know if you're if you're dealing with big data.
Definitely go for Mongo db.
It's killable.
It's fast and you know it's it's just as good as any other option out there if not better.
Also the content management and delivery mobile and social infrastructure user data management and data.
So if you have any of these then it will be a very good idea to use Mago de.
OK so we're going to stop here for now.
And in the next video we're going to see how we can install Mungiki be on our virtual machine.
So until the next video happy coding.