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.