1 00:00:04,060 --> 00:00:10,450 ‫So B plus three and DBMS considerations, take a sip of tea, take a sip of coffee, relax a little 2 00:00:10,450 --> 00:00:10,620 ‫bit. 3 00:00:10,630 --> 00:00:17,200 ‫I know it's a long video, guys, but I think I think we need to discuss these details. 4 00:00:17,350 --> 00:00:19,480 ‫You can pause the video and come back later. 5 00:00:19,630 --> 00:00:20,070 ‫All right. 6 00:00:20,100 --> 00:00:20,890 ‫All right. 7 00:00:21,100 --> 00:00:23,980 ‫This is there is there is a lot of content there. 8 00:00:23,980 --> 00:00:25,030 ‫Ask me questions. 9 00:00:25,030 --> 00:00:28,630 ‫Ask questions as you as you encounter them. 10 00:00:28,630 --> 00:00:32,230 ‫But this is very, very interesting to understand now. 11 00:00:32,320 --> 00:00:38,820 ‫So B plus trees and DBMS considerations, but there is an additional cost here, which is the leaf pointer. 12 00:00:38,950 --> 00:00:48,970 ‫Again, for, for instance, my sequel, A.B. PostgreSQL Sever all have this leaf pointers that points 13 00:00:48,970 --> 00:00:58,990 ‫to the next of the next leaf point in the B plus three leaves leaf nodes wired tiger in Mongo DB. 14 00:00:59,290 --> 00:01:07,690 ‫Yes, Mongo TV does use a B plus trees through this wired tiger database engine, which I have. 15 00:01:07,810 --> 00:01:12,190 ‫I have a lecture about data database engines. 16 00:01:12,220 --> 00:01:12,570 ‫Right. 17 00:01:13,780 --> 00:01:19,810 ‫Talk about that and why a tiger is a B plus three based engine. 18 00:01:19,810 --> 00:01:29,170 ‫And also they have a variant like structure mastery that that doesn't have this pointer from forfour 19 00:01:29,740 --> 00:01:30,940 ‫design decisions. 20 00:01:31,330 --> 00:01:32,680 ‫Those guys are smart. 21 00:01:32,890 --> 00:01:35,680 ‫They only include things where they absolutely. 22 00:01:35,680 --> 00:01:38,500 ‫This is like, OK, I have quiz, who cares? 23 00:01:38,890 --> 00:01:42,550 ‫You're not going to do a ranch cause a mango, for instance, OK? 24 00:01:42,580 --> 00:01:47,230 ‫You're not going to search for a range of keys. 25 00:01:47,230 --> 00:01:47,920 ‫Don't do that. 26 00:01:49,540 --> 00:01:51,790 ‫One node fits RDBMS page. 27 00:01:51,790 --> 00:01:57,520 ‫As I discussed, most differences do that can also fit internal nodes easily memory for fast reversal 28 00:01:57,520 --> 00:02:01,330 ‫because the nodes are now tinier. 29 00:02:01,540 --> 00:02:04,450 ‫I guess you can post a lot. 30 00:02:04,450 --> 00:02:09,130 ‫A lot, a lot of elements right in these internal nodes. 31 00:02:09,250 --> 00:02:12,640 ‫You can fit these internal nodes in memory easier. 32 00:02:12,790 --> 00:02:19,240 ‫So the traversal a single IO will give you way more elements. 33 00:02:19,520 --> 00:02:22,420 ‫As a result, it's a way faster. 34 00:02:22,840 --> 00:02:32,260 ‫Plus this again, it really depends on what are you indexing on this canford and memory fits at Gwynedd 35 00:02:32,260 --> 00:02:33,130 ‫or yolked. 36 00:02:33,790 --> 00:02:41,530 ‫It's not as easy for the memory, but still can usually the the internals as not as busy as the leaf 37 00:02:41,530 --> 00:02:46,450 ‫nodes in a P blusterous leave nodes can live in the data files in the heap. 38 00:02:46,450 --> 00:02:47,920 ‫That does absolutely fine. 39 00:02:49,270 --> 00:02:49,720 ‫It is. 40 00:02:49,720 --> 00:02:58,540 ‫Obviously you can try to put them in memory, but if the values, the value that points to is expensive, 41 00:02:58,540 --> 00:03:01,330 ‫then sometimes it is not possible. 42 00:03:02,350 --> 00:03:04,300 ‫Most Divinities B blusterous. 43 00:03:05,110 --> 00:03:08,230 ‫So is an example of the storage cost here. 44 00:03:08,500 --> 00:03:13,540 ‫This really I said should between Cote's here but doesn't have to write. 45 00:03:13,930 --> 00:03:17,890 ‫The B3 index works best when it's in memory. 46 00:03:18,550 --> 00:03:25,390 ‫So when you load up your database, let's say you have a table with five indexes, you can try to put 47 00:03:25,390 --> 00:03:30,190 ‫all the indexes of memory and you can check the sizes of the indexes by doing a query on the database 48 00:03:30,190 --> 00:03:33,550 ‫and say, see, can I fit this entire index in memory? 49 00:03:33,910 --> 00:03:40,300 ‫Most of the times the indexes are tiny, like if you have don't have large files, but if it's if it's 50 00:03:40,300 --> 00:03:42,550 ‫large, there's some databases. 51 00:03:42,550 --> 00:03:43,270 ‫Make that choice. 52 00:03:43,270 --> 00:03:52,300 ‫OK, I'm going to only put the internal nodes in memory so that my traversal are so fast because I cache 53 00:03:52,300 --> 00:03:53,890 ‫the page and these are tiny. 54 00:03:54,670 --> 00:03:55,020 ‫Right. 55 00:03:55,510 --> 00:04:03,430 ‫And Usry not necessarily time because these are pages of the same size, but I have way more elements 56 00:04:03,430 --> 00:04:09,760 ‫and as a result I can traverse way more and this could fit in disk. 57 00:04:09,760 --> 00:04:14,890 ‫But you can definitely put in memory nothing that stops you from doing that by. 58 00:04:16,100 --> 00:04:22,670 ‫If they fit again, it really depends on this on this pointer and also depends on what you're working 59 00:04:22,670 --> 00:04:23,190 ‫on, right.