1 00:00:01,090 --> 00:00:03,210 Just like in the previous sections, 2 00:00:03,210 --> 00:00:05,810 before we dive into a new technology, 3 00:00:05,810 --> 00:00:08,590 let's actually learn what it's all about. 4 00:00:08,590 --> 00:00:12,180 So in this case, let's learn what MongoDB actually is, 5 00:00:12,180 --> 00:00:14,750 how it works, and a quick overview 6 00:00:14,750 --> 00:00:18,600 of how it compares to more traditional databases. 7 00:00:18,600 --> 00:00:21,340 And let's begin with a simple overview. 8 00:00:21,340 --> 00:00:24,830 So MongoDB is obviously a database, 9 00:00:24,830 --> 00:00:27,870 and it's a so-called NoSQL database. 10 00:00:27,870 --> 00:00:30,930 Now some people also say No S Q L, 11 00:00:30,930 --> 00:00:34,240 but I'm just gonna keep saying "no sequel", all right? 12 00:00:34,240 --> 00:00:37,010 Now, the other type of database, which is 13 00:00:37,010 --> 00:00:40,620 sort of more traditional, is the relational database, 14 00:00:40,620 --> 00:00:43,760 which NoSQL is often compared to. 15 00:00:43,760 --> 00:00:48,330 Anyway, in Mongo, which we can also say instead of MongoDB, 16 00:00:48,330 --> 00:00:52,570 each database can contain one or more collections. 17 00:00:52,570 --> 00:00:55,100 So if you actually are coming from one of 18 00:00:55,100 --> 00:00:58,530 these more traditional relational database systems, 19 00:00:58,530 --> 00:01:02,760 you can think of a collection as a table of data. 20 00:01:02,760 --> 00:01:05,520 Then, each collection can contain one 21 00:01:05,520 --> 00:01:09,130 or more data structures called documents, 22 00:01:09,130 --> 00:01:11,870 and again, in a relational database, 23 00:01:11,870 --> 00:01:15,380 a document would be a row in a table. 24 00:01:15,380 --> 00:01:17,770 So each document contains the data 25 00:01:17,770 --> 00:01:20,600 about one single entity, for example, 26 00:01:20,600 --> 00:01:24,870 one blog post or one user or one review, 27 00:01:24,870 --> 00:01:26,780 or anything else, really. 28 00:01:26,780 --> 00:01:29,030 You get the point, right? 29 00:01:29,030 --> 00:01:32,270 Now the collection is like the parent structure 30 00:01:32,270 --> 00:01:34,730 that contains all these entities. 31 00:01:34,730 --> 00:01:38,120 For example, a blog collection for all posts, 32 00:01:38,120 --> 00:01:41,730 a users collection or a reviews collection. 33 00:01:41,730 --> 00:01:44,060 And you can also see here that the document 34 00:01:44,060 --> 00:01:47,740 has a data format that looks a lot like JSON, 35 00:01:47,740 --> 00:01:49,810 which will make our work a lot easier 36 00:01:49,810 --> 00:01:52,520 when we start dealing with these documents. 37 00:01:52,520 --> 00:01:55,180 And of course we will talk a lot about this later, 38 00:01:55,180 --> 00:01:58,543 but for now on, let's learn about Mongo's main features. 39 00:01:59,460 --> 00:02:02,260 So, according to MongoDB's website, 40 00:02:02,260 --> 00:02:05,990 MongoDB is a document database with the scalability 41 00:02:05,990 --> 00:02:08,330 and flexibility that you want, 42 00:02:08,330 --> 00:02:12,200 and with the querying and indexing that you need. 43 00:02:12,200 --> 00:02:14,710 Now, that sounds a bit over the top, 44 00:02:14,710 --> 00:02:17,503 so let's try to understand what this actually means. 45 00:02:18,490 --> 00:02:23,250 So, as we saw before, MongoDB is a document-based database, 46 00:02:23,250 --> 00:02:25,750 so it stores data in documents which 47 00:02:25,750 --> 00:02:29,660 are field-value paired data structures like JSON. 48 00:02:29,660 --> 00:02:33,020 So again, it stores data in these document 49 00:02:33,020 --> 00:02:34,840 instead of rows in a table 50 00:02:34,840 --> 00:02:37,530 like in traditional relational databases. 51 00:02:37,530 --> 00:02:39,930 It's therefore a NoSQL database 52 00:02:39,930 --> 00:02:42,190 and not a relational one. 53 00:02:42,190 --> 00:02:45,690 Also, MongoDB has built-in scalability, 54 00:02:45,690 --> 00:02:48,360 making it very easy to distribute data 55 00:02:48,360 --> 00:02:50,920 across multiple machines as your apps 56 00:02:50,920 --> 00:02:52,620 get more and more users 57 00:02:52,620 --> 00:02:56,090 and starts generating a ton of data. 58 00:02:56,090 --> 00:02:59,710 So whatever you do, MongoDB will make it very easy 59 00:02:59,710 --> 00:03:01,110 for you to grow. 60 00:03:01,110 --> 00:03:04,010 Next up, another big feature of MongoDB 61 00:03:04,010 --> 00:03:06,360 is its great flexibility. 62 00:03:06,360 --> 00:03:10,210 So there is no need to define a document data schema 63 00:03:10,210 --> 00:03:12,210 before filling it with data, 64 00:03:12,210 --> 00:03:15,460 meaning that each document can have a different number 65 00:03:15,460 --> 00:03:17,160 and type of fields. 66 00:03:17,160 --> 00:03:20,120 And we can also change these fields all the time. 67 00:03:20,120 --> 00:03:22,130 And all this is really in line 68 00:03:22,130 --> 00:03:24,460 with some real-world business situations, 69 00:03:24,460 --> 00:03:26,690 and therefore can become pretty useful. 70 00:03:26,690 --> 00:03:31,550 MongoDB is also a very performant database system. 71 00:03:31,550 --> 00:03:34,680 Thanks to features like embedded data models, 72 00:03:34,680 --> 00:03:37,645 indexing, sharding, the flexible documents 73 00:03:37,645 --> 00:03:41,290 that we already talked about, native duplication 74 00:03:41,290 --> 00:03:43,010 and so much more. 75 00:03:43,010 --> 00:03:45,850 And you don't need to know all of this, of course, 76 00:03:45,850 --> 00:03:50,320 but it's sure nice to know that MongoDB is highly performant 77 00:03:50,320 --> 00:03:52,100 if we need it to be. 78 00:03:52,100 --> 00:03:55,270 Finally, I just wanted to add that MongoDB 79 00:03:55,270 --> 00:03:57,710 is a free and open-source database, 80 00:03:57,710 --> 00:04:01,350 published under the SSPL license. 81 00:04:01,350 --> 00:04:04,700 So in summary, we can say that MongoDB 82 00:04:04,700 --> 00:04:06,770 is a great database system 83 00:04:06,770 --> 00:04:09,600 to build many types of modern, scalable 84 00:04:09,600 --> 00:04:11,900 and flexible web applications. 85 00:04:11,900 --> 00:04:15,450 And in fact, Mongo is probably the most used database 86 00:04:15,450 --> 00:04:18,250 with no JS, and so it's a perfect fit 87 00:04:18,250 --> 00:04:20,690 for us to use in this course. 88 00:04:20,690 --> 00:04:22,970 Okay, now let's talk a bit deeper 89 00:04:22,970 --> 00:04:25,910 about these documents, and returning 90 00:04:25,910 --> 00:04:28,540 to our blog posts example from the beginning, 91 00:04:28,540 --> 00:04:31,330 this could be a very simple representation 92 00:04:31,330 --> 00:04:34,140 of a single post document, right? 93 00:04:34,140 --> 00:04:36,720 And now just for the sake of comparison, 94 00:04:36,720 --> 00:04:38,930 here is how that exact same data 95 00:04:38,930 --> 00:04:42,250 could look like as a row in a relational database 96 00:04:42,250 --> 00:04:45,580 like MySQL, or even in an Excel spreadsheet, 97 00:04:45,580 --> 00:04:47,640 if you're more used to that. 98 00:04:47,640 --> 00:04:49,730 So as I mentioned a bit earlier, 99 00:04:49,730 --> 00:04:53,190 MongoDB uses a data format similar to JSON 100 00:04:53,190 --> 00:04:56,070 for data storage called BSON. 101 00:04:56,070 --> 00:04:58,970 It looks basically the same as JSON, 102 00:04:58,970 --> 00:05:01,650 but it's typed, meaning that all values 103 00:05:01,650 --> 00:05:05,450 will have a data type such as string, Boolean, 104 00:05:05,450 --> 00:05:09,050 date and teacher, double object or more. 105 00:05:09,050 --> 00:05:11,890 We will learn all about this later in practice. 106 00:05:11,890 --> 00:05:15,030 So what this means is that all MongoDB documents 107 00:05:15,030 --> 00:05:16,700 will actually be typed, 108 00:05:16,700 --> 00:05:20,220 which is different from JSON, all right? 109 00:05:20,220 --> 00:05:23,830 Now just like JSON, these BSON documents 110 00:05:23,830 --> 00:05:26,570 will also have fields and data is stored 111 00:05:26,570 --> 00:05:28,270 in key value pairs. 112 00:05:28,270 --> 00:05:30,840 On the other hand, in a relational database, 113 00:05:30,840 --> 00:05:33,730 each field is called a column. 114 00:05:33,730 --> 00:05:35,400 So here again you can see how 115 00:05:35,400 --> 00:05:38,920 these databases arrange data in table structures 116 00:05:38,920 --> 00:05:42,590 while our JSON data is so much more flexible. 117 00:05:42,590 --> 00:05:44,300 Take for example the tags field, 118 00:05:44,300 --> 00:05:46,170 where we actually have an array, 119 00:05:46,170 --> 00:05:50,470 so we have basically multiple values for one field, right? 120 00:05:50,470 --> 00:05:54,140 So MongoDB, space and DV in this case. 121 00:05:54,140 --> 00:05:57,040 But in relational databases, that's not really allowed. 122 00:05:57,040 --> 00:06:00,020 We cannot have multiple values in one field, 123 00:06:00,020 --> 00:06:03,100 and so we would actually have to find workarounds for this 124 00:06:03,100 --> 00:06:05,150 which could then involve more work 125 00:06:05,150 --> 00:06:07,550 and more overall complication. 126 00:06:07,550 --> 00:06:10,540 Now another extremely important feature in MongoDB 127 00:06:10,540 --> 00:06:13,040 is the concept of embedded documents, 128 00:06:13,040 --> 00:06:16,120 which is, again, something not present 129 00:06:16,120 --> 00:06:18,290 in relational databases. 130 00:06:18,290 --> 00:06:19,970 So in our comments field here, 131 00:06:19,970 --> 00:06:23,050 we have an array which contains three objects. 132 00:06:23,050 --> 00:06:24,500 One for each document, 133 00:06:24,500 --> 00:06:26,280 and each of them could actually be 134 00:06:26,280 --> 00:06:28,700 its own document, right? 135 00:06:28,700 --> 00:06:31,360 So just imagine we had a comments collection 136 00:06:31,360 --> 00:06:34,550 which contained a bunch of comment documents. 137 00:06:34,550 --> 00:06:37,670 Each of them could actually look exactly like this, 138 00:06:37,670 --> 00:06:40,600 so with an author and with the comment text, 139 00:06:40,600 --> 00:06:42,200 but instead of doing that, 140 00:06:42,200 --> 00:06:45,850 we include these comments right into the blog post document, 141 00:06:45,850 --> 00:06:49,610 so in other words, we embed the comment documents 142 00:06:49,610 --> 00:06:52,270 right into the post document. 143 00:06:52,270 --> 00:06:55,410 So this process of embedding, or de-normalizing 144 00:06:55,410 --> 00:06:59,070 as we can also call it, is basically to include, 145 00:06:59,070 --> 00:07:01,930 so, to embed, some related data all 146 00:07:01,930 --> 00:07:04,040 into one single document. 147 00:07:04,040 --> 00:07:07,540 In this example, the comments are related to the post, 148 00:07:07,540 --> 00:07:10,880 and so they are included in the same document. 149 00:07:10,880 --> 00:07:13,380 And this makes a database more performant 150 00:07:13,380 --> 00:07:15,760 in some situations because this way, 151 00:07:15,760 --> 00:07:17,340 it can be easier to read all 152 00:07:17,340 --> 00:07:20,150 the data that we need all at once. 153 00:07:20,150 --> 00:07:23,270 And this is something that we're gonna talk about a lot 154 00:07:23,270 --> 00:07:25,320 when learning about data modeling, 155 00:07:25,320 --> 00:07:28,720 but for now, I hope that this still makes sense to you. 156 00:07:28,720 --> 00:07:31,850 Now, the opposite of embedding or de-normalizing, 157 00:07:31,850 --> 00:07:35,520 is normalizing, and that's how the data is always modeled 158 00:07:35,520 --> 00:07:37,200 in relational databases. 159 00:07:37,200 --> 00:07:40,430 So in that case, it's not possible to embed data, 160 00:07:40,430 --> 00:07:42,070 and so the solution is to create 161 00:07:42,070 --> 00:07:44,480 a whole new table for the comments 162 00:07:44,480 --> 00:07:47,320 and then join the tables by referencing 163 00:07:47,320 --> 00:07:50,250 to the ID field of the comments table. 164 00:07:50,250 --> 00:07:52,590 Now we're not gonna use relational databases 165 00:07:52,590 --> 00:07:55,460 in this course, but I believe it's still important 166 00:07:55,460 --> 00:07:57,510 to know the differences if you wanna become 167 00:07:57,510 --> 00:07:59,630 a good back-end developer. 168 00:07:59,630 --> 00:08:01,940 Anyway, and now just to finish, 169 00:08:01,940 --> 00:08:04,810 two more things about BSON documents. 170 00:08:04,810 --> 00:08:07,510 First, the maximum size for each document 171 00:08:07,510 --> 00:08:12,120 is currently 16 MB, but this might increase in the future. 172 00:08:12,120 --> 00:08:16,180 And second, each document contains a unique ID, 173 00:08:16,180 --> 00:08:19,900 which acts as a primary key of that document. 174 00:08:19,900 --> 00:08:23,780 It's automatically generated with the object ID data type 175 00:08:23,780 --> 00:08:26,000 each time there is a new document, 176 00:08:26,000 --> 00:08:28,605 and so we don't have to worry about it. 177 00:08:28,605 --> 00:08:32,240 All right, and that should be a brief enough overview 178 00:08:32,240 --> 00:08:33,610 to get us started, 179 00:08:33,610 --> 00:08:37,210 and to actually use MongoDB from the next lecture on. 180 00:08:37,210 --> 00:08:38,873 So, let's move on now.