1 00:00:04,500 --> 00:00:15,060 ‫OK, what's the limitations of batteries, batteries are not perfect, and that's why it was a variation 2 00:00:15,060 --> 00:00:17,730 ‫was created to solve these limitations. 3 00:00:18,420 --> 00:00:25,530 ‫So the first problem is elements and all nodes store both the keys and the values. 4 00:00:25,860 --> 00:00:26,230 ‫Right. 5 00:00:27,510 --> 00:00:36,540 ‫And because we store the key and the value in every single node, then you can only store so many elements, 6 00:00:36,750 --> 00:00:38,360 ‫because let's go back here and see. 7 00:00:38,550 --> 00:00:39,270 ‫Here's why. 8 00:00:40,440 --> 00:00:41,940 ‫If I'm reading this node. 9 00:00:42,810 --> 00:00:43,200 ‫Right. 10 00:00:44,260 --> 00:00:50,140 ‫If I'm reading this note or this page, because are effectively the same thing they base, then you're 11 00:00:50,140 --> 00:00:55,250 ‫going to put pull keys four and eight and their corresponding values. 12 00:00:55,720 --> 00:01:02,590 ‫So if you're searching for the key one, you really just use the key ID and use the values. 13 00:01:02,890 --> 00:01:06,670 ‫So you wasted precious memory space. 14 00:01:08,080 --> 00:01:13,480 ‫That you didn't really use, if you think about so alternatively. 15 00:01:14,770 --> 00:01:23,770 ‫I can if I'm studying the values in that page, in the note, then these values are not just this is 16 00:01:24,110 --> 00:01:29,590 ‫this could be up to 64 bit so or some people still guedes. 17 00:01:29,740 --> 00:01:38,740 ‫So think twice when you create an index on it, on a UUID or a string, because that buppie exists right 18 00:01:38,740 --> 00:01:39,070 ‫here. 19 00:01:39,070 --> 00:01:39,490 ‫Right. 20 00:01:40,690 --> 00:01:49,870 ‫Like if if you create, for example, a primary key right on a Stringfield, then this string values 21 00:01:49,870 --> 00:01:55,360 ‫are stored on one B plus to restore them and then lether, which are we going to discuss. 22 00:01:55,360 --> 00:02:00,100 ‫But, but they are stored and when they are stored they take more space. 23 00:02:00,100 --> 00:02:04,510 ‫More space means I can fit less elements. 24 00:02:05,900 --> 00:02:11,240 ‫In a page or an A. And if I had this element, then I need to read more. 25 00:02:12,790 --> 00:02:19,810 ‫Right, because I need to I need to put more nodes, more nodes mean more pages, more pages means more 26 00:02:19,810 --> 00:02:23,210 ‫IO, more IO means slow. 27 00:02:24,520 --> 00:02:28,000 ‫So that's the trickier elements. 28 00:02:28,030 --> 00:02:29,050 ‫No, no, still both. 29 00:02:29,560 --> 00:02:36,430 ‫So they take more space, thus require more IO and can slow down the traversal. 30 00:02:37,660 --> 00:02:38,780 ‫So that's the trick here. 31 00:02:39,250 --> 00:02:40,990 ‫So we're Mitsos and what else? 32 00:02:40,990 --> 00:02:44,070 ‫If we don't know the value you need to store the value at some point. 33 00:02:44,080 --> 00:02:44,360 ‫Right? 34 00:02:44,980 --> 00:02:52,000 ‫Well, when we're going to talk about that, another limitation of the betrayal's range queries are 35 00:02:52,000 --> 00:02:58,540 ‫slow because of the random access, because you're jumping back and forth. 36 00:02:58,540 --> 00:03:04,000 ‫If you give us if you vesku give me all the values between one and five and I'm going to show you an 37 00:03:04,000 --> 00:03:10,330 ‫example in a minute, then we're going to jump all over the place to find one and then find two and 38 00:03:10,330 --> 00:03:12,380 ‫find three and find four and then five. 39 00:03:12,380 --> 00:03:12,840 ‫Five. 40 00:03:13,270 --> 00:03:13,690 ‫Right. 41 00:03:13,930 --> 00:03:17,830 ‫I have to do five different reversals to find these values. 42 00:03:18,010 --> 00:03:20,740 ‫Not necessarily might be a little bit less if you're lucky. 43 00:03:20,740 --> 00:03:23,110 ‫But that's that's what I need to go. 44 00:03:23,260 --> 00:03:24,920 ‫It's almost random, right. 45 00:03:25,150 --> 00:03:28,820 ‫Despite them being very tucked next to each other. 46 00:03:29,220 --> 00:03:29,850 ‫The keys. 47 00:03:30,460 --> 00:03:30,800 ‫Right. 48 00:03:31,110 --> 00:03:33,430 ‫Give me old should be keys, not values. 49 00:03:33,430 --> 00:03:34,340 ‫But you get my point. 50 00:03:34,360 --> 00:03:42,850 ‫I'm searching for these values, these keys effectively, but B plus three solve both these problems. 51 00:03:43,030 --> 00:03:50,020 ‫Another problem with this is like it's hard to fit internal nodes in memory when you have all these 52 00:03:50,020 --> 00:03:51,580 ‫values right. 53 00:03:51,580 --> 00:04:01,060 ‫In in in each element because you have all these values, then I can't really fit stuff in memory, 54 00:04:01,090 --> 00:04:07,710 ‫especially like I don't know if I have a primary key on on a UID field or on a stringfield. 55 00:04:07,840 --> 00:04:08,150 ‫Right. 56 00:04:08,500 --> 00:04:16,270 ‫Then it becomes very expensive to store this index or this Vetri in memory because it costs a lot to 57 00:04:16,270 --> 00:04:20,830 ‫traverse as an example for why batteries can be bad for Orange County. 58 00:04:20,830 --> 00:04:29,290 ‫So I'm going to now find all the rows I'd between four and nine in this in this particular battery. 59 00:04:29,290 --> 00:04:38,430 ‫So I'm looking for four and I want to pull all these rows so I can look up Pete, Edmund and Edmund 60 00:04:38,440 --> 00:04:38,880 ‫Sarah. 61 00:04:38,950 --> 00:04:43,120 ‫And so what I'm going to do is, OK, the search number for oh, we were lucky. 62 00:04:43,120 --> 00:04:44,080 ‫We found number four. 63 00:04:44,110 --> 00:04:46,750 ‫OK, let's find let's find number five was five. 64 00:04:46,990 --> 00:04:48,610 ‫Well, five is between four and eight. 65 00:04:48,610 --> 00:04:56,260 ‫So we jump to this data point, a child's point of find to this page, page Poynton and get to six or 66 00:04:56,260 --> 00:04:58,810 ‫Wuhl five is actually less than six. 67 00:04:58,810 --> 00:04:59,980 ‫So let's jump another. 68 00:04:59,980 --> 00:05:03,850 ‫I also one iota I 030 we found five. 69 00:05:03,850 --> 00:05:08,500 ‫OK, let's find, let's go ahead and find six. 70 00:05:08,530 --> 00:05:09,160 ‫All six. 71 00:05:09,160 --> 00:05:13,300 ‫We just actually read in a minute that goes oh it's in memory hot right. 72 00:05:13,600 --> 00:05:23,590 ‫Unless we had to throw it back into the desk for full LRU reasons at least recently. 73 00:05:23,590 --> 00:05:25,690 ‫Use cash like if we throw it back. 74 00:05:26,200 --> 00:05:30,370 ‫But is there ok we find six or seven go and find seven. 75 00:05:30,370 --> 00:05:31,200 ‫We found it. 76 00:05:31,930 --> 00:05:32,350 ‫All right. 77 00:05:32,350 --> 00:05:33,040 ‫How about eight. 78 00:05:33,700 --> 00:05:35,470 ‫Eight is all. 79 00:05:35,470 --> 00:05:36,220 ‫There you go. 80 00:05:36,640 --> 00:05:39,790 ‫I put on the road how one nine nine is in this side. 81 00:05:39,790 --> 00:05:40,630 ‫Go here. 82 00:05:40,630 --> 00:05:44,140 ‫We read this page and then go on and then to the left. 83 00:05:44,590 --> 00:05:46,830 ‫This is nine and then we find the value. 84 00:05:47,440 --> 00:05:52,000 ‫So look, I don't know what how what we have done to find this any might look at this. 85 00:05:52,300 --> 00:05:53,410 ‫I say it's not that bad. 86 00:05:53,920 --> 00:06:02,350 ‫But we thrashed the index to look for these five values, despite them technically being next to each 87 00:06:02,350 --> 00:06:02,560 ‫other. 88 00:06:02,560 --> 00:06:03,520 ‫They are sorted. 89 00:06:03,850 --> 00:06:05,740 ‫They are next to each other. 90 00:06:05,870 --> 00:06:06,200 ‫Right. 91 00:06:07,000 --> 00:06:10,360 ‫And that's another thing that B, B plus trees solved. 92 00:06:10,630 --> 00:06:18,880 ‫Another thing, B plus three solve is like it tries not to put values in these kind of hot searches. 93 00:06:18,880 --> 00:06:26,260 ‫It tries to to make this as slim as possible to search and pushes all this all the data to the leaves, 94 00:06:26,260 --> 00:06:27,580 ‫as we can see in the minute.