Indexes

[00:00:00]
>> Scott Moss: And the last thing that I wanted to talk about is gonna be indexes in a little more detail, specifically compound indexes, which are so fantastic in Mongo, one of my favorite features. Absolutely my application would die without compound indexes, it's just amazing. But just we're gonna talk about indexes for just a little bit.

[00:00:23]
Indexes are really complicated, and I'm definitely not like a database admin that knows everything about low level indexes, but I can tell you about my experience in what indexes are in Mongo. But you can think of indexes very much like this. So if I have an object with keys, right?

[00:00:42]
Key and value, very much like the router that we built, I'm sorry, that was yesterday's course, different group, sorry. [LAUGH] Yeah, so if you have an object with a key and a value, we can now use constant time to go find the location, right, because if we know what the key is we can go straight to this object and get the value.

[00:01:03]
If you know how hash tables work then that's what this is, it's a hash table. But basically what this means is we have the address we can go straight to it, we don't have to search for it. If this was an array, I might have to search an entire array to figure out where value is, whereas if it's an object, I can go straight to it.

[00:01:20]
Our index's job, at the end of the day, is to do that for your database. So right, we wanna be able to go straight to a value without having to search the whole collection for it. Because if you have a million things in your collection, and the thing you're trying to get is all at the end, you just scanned a million things just to get one thing.

[00:01:36]
That is so like that like you just couldn't scale an application like that. So, databases cannot live without indexes and Mongo is not the only database with indexes. This is just how indexes work, they're all implemented differently but this is how indexes kinda work or this is the purpose of them.

[00:01:52]
How it actually works in Mongo, basically the indexes are saved in a file, and the files are basically kept in memory, the indexes, and then Mongo will read the indexes as address as a pointer so it will find the actual value that's somewhere in memory. So basically if you have, if you're only querying with indexes, you're basically reading from memory and it's free.

[00:02:16]
So you don't have to use something like or something like that. Yes.
>> Speaker 2: What if you run out of memory?
>> Scott Moss: If you're out of memory you have to throw money at it, or you've got to write some better indexes. That's a really complicated answer. I could tell you about that like we're done with this, how Mongo allocates memory for indexes and what it does because it's very scientific.

[00:02:38]
And actually I just learned this myself not too long ago, talking with the Mongo experts. But yeah, the short answer is throw money at it or fix your indexes. Yeah. Okay cool, so now that we have a primer on indexes, guess what? You've already built an index before.

[00:02:52]
When you put unique true, that was an index. That wasn't a validation. You told Mongo, hey, every time I create a user that has a first name and a last name in an email and they all have unique true, I need you to store a reference to this user somewhere.

[00:03:07]
That way when someone tries to create another one, I'm going to check to see if this value already exists, and if it does, I'm going to error out. And it can do that efficiently because you created an index for it. You taught Mongo where the address for these users were so it can find them immediately on insert.

[00:03:23]
So as soon as someone inserts something you're like I know exactly where this is, lemme go, no, sorry, same first name can't do it. Whereas if you didn't have an index, you would merely have to, on insert yourself, you have to write a middleware that will scan the entire user database and check every single name yourself to see if it exists, and you would throw an error.

[00:03:42]
So imagine how inefficient that would be. It would grow it's end, so that would grow as big as users you have. The more users you have, the slower that would be, so you don't wanna do that.