MongoDB with Async Python Transcripts
Chapter: Performance Tuning
Lecture: Releases Counted in 1ms
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Let's go back and think about how our code is being used here. So we use our last updated date,
0:09
but we also might care about the created date. So let's add something in real similar. I won't type it in again. We're going to have created date.
0:17
Could be ascending or descending. Let's go with ascending. That's fine. Another one we might want to ask is, show me all of
0:25
the packages that has this author email set. So same type of deal, we're going to have this key is going to be author email.
0:34
I don't think we'll ever sort by it. So that doesn't matter. And we'll just have author email ascend.
0:41
Similarly, we might want to go to a particular release up here and say I want the one with
0:47
the major version equal to this or the minor version equal that or the build version equal to that as well. Even possibly the created time.
0:55
Let's go ahead and throw that in there as well. So how do we speak about the releases?
1:01
It won't be capital release, it will be from this document's perspective. So it's releases dot created date.
1:12
And let's call this releases created ascending. So this dotted notation here will allow us to traverse into the hierarchy, right?
1:22
you see dot, that means go into the sub object and be for as far as indexes go, just forget
1:29
that there's an list here, just refer to it as the thing as if there was one of them in
1:34
there. So in this case, if there was one, it'd be a single release. Similarly, if you
1:38
want to index on this ID here, we would just say, maintainer IDs flat, even though it's
1:44
a list of items. We also might want those three major minor build. So we would put releases
1:52
dot major version, or at least it's a minor version, or at least it's a build version,
1:55
right and give them names. But what we were asking before was not major version, minor version,
2:03
or build version, we were asking for all three, I want this major and this minor and that build
2:09
version using element match. And so in order to do that, we have to do something a little bit more
2:15
interesting. So you might have been wondering so far, like, why is this a list? That's weird.
2:21
That's a little weird, Michael. Why is that the case? Because into this list, we can put more
2:26
than one thing. So we can have the major version, the minor version, and the build version,
2:37
all three of those in here. And this will be releases version, let's call this ascending.
2:43
So this will allow us to use that when we're asking for all three of these. Although it gets
2:49
It's a little tricky for sorting, you can only sort them all the sending are all descending by that particular thing.
2:57
You can't mix and match like sort by major ascending but minor descending. But why would you ever do that in this data model?
3:03
So it's probably all right. Let's run this again. Beanie will create all these indexes. And we'll see where we are.
3:11
Heading back over here, refreshing our indexes. Whoa, look at that. We have our composite key on all three of those. That's pretty cool.
3:21
And then the others would be just as you expect. So let's run our code again. And this time we can search the database for packages.
3:29
So F, and instead of asking you over and over, we said, let's find a package, we're going to look for FastAPI, we're going to do that 100 times.
3:41
So we got it back in 300 milliseconds. That's pretty fast, isn't it? You should feel pretty good about that.
3:46
So that's 0.3 milliseconds to find the package and all of its releases and pull it back.
3:53
You can see right here with 154 releases, and as well as like all that description text and everything that is epically fast, we could do better.
4:02
You'll see we're going to do better actually. Now if you say I want to find all the packages rather, I want to count how many packages
4:10
there are with the version 728. That took 100 milliseconds 135 milliseconds, that's a 10th of
4:17
a millisecond. We went through a just under a quarter million releases. They are interspersed
4:26
within 5000 different records packages as lists embedded inside of them. quarter million of them
4:34
embedded inside 5000 different records, we were able to ask how many of them are have a version
4:42
exactly 7.2 dot eight, there are six apparently. But we got that answer in 0.135 milliseconds.
4:51
That is ridiculous. indexes, their magic. Let's see if I can come over here and remove all of these. Try it one more time.
5:13
Let's just say find a package. Look at this. Holy moly. 2000 milliseconds or 20 milliseconds per one query.
5:27
All we had to do to make that happen, a little bit of this, a little bit of this.
5:33
Think about where is your app's performance, what kind of queries are it running.
5:36
You've already thought a lot about this because you've thought about the document design.
5:41
So you're like, well, we're going to need this data with it and we're going to ask questions like this. So you probably have a really good idea here.
5:47
Let's run it one more time just to see, we'll get it back. Look at it this time. Look at this. 89 milliseconds.
5:56
What is 89 over 100 divided by 1000 to get it into seconds? 0.0009 seconds. Incredible. So less than a
6:08
millisecond to go through those quarter million releases embedded and sprinkled throughout 5,000
6:15
packages. Indexes, they are so awesome. Don't forget to turn on your indexes. Again, another
6:25
Another kind of question we could ask is the most recently updated ones. That ran in four milliseconds per query. Still seems kind of slow, doesn't it?
6:34
We're not done. Indexes are awesome, but they are not the end-all be-all. There's still more to do here.