Now, one of the things that we can do in MongoDB is actually explain how a query is executed. Now, to do this in Python, there's a completely different command using the MongoDB shell. But we're using our IPython notebook here or our Jupyter notebook here. We can perform the explain by running a commands on the mflix database. The explain command will be sent by defining where we want to find, or what the command on which collection we want to find to perform. In this case, the "find" on "movies". And what's the filter that we want to actually execute. For example, "tomatoes.viewer.numReviews" greater than 10. It's a nice going to do. And also, we can define the type of verbosity of this explain command. Once we run this, we can see the execution of this query. This different stages by which the execution of the query needed to go through. If the stage is an index scan or not, if it has it's FETCH stage, and a bunch of other information that is really, really important for us to understand if the actual execution is being optimum or close to that. Now, I'm not going to go into too much deep in terms of the weeds of the query engine in all the stages it performs. But you should be aware of the fact that every single query that is executed in MongoDB and in other databases will go through different stages. For example, COLLSCAN basically stands for a collection scan. This is the worst performance you can get because it will go into all different documents of your collection and try to match them against your query criteria. But there's like FETCH, SORT, IXSCAN, SHARD_MERGE, bunch of different stages that make part of your query. You will find some of them on your explain output. But getting back to the explain itself of our query, which is a filter on "tomatoes.viewer.numReviews" greater than 10, we can see here this field called winningPlan. It takes an inputStage is a direction forward. It has a couple of other things which are interesting. For example, the fact that it is passing though an index scan into the stage. Another important thing here to raise up is the fact that it is using index. And the index that's been used for this query is this tomatoes.viewer.numReviews -1. So it's using a single index to perform this particular query and return results in a very, very efficient manner. But getting back to our list of indexes, there's a particular index that I want to raise your attention to. This one here, title_text_cast_text_directors_text. Now, this means that this index here is a fts, full-text search text. Now, text search indexes are slightly different from, for example, single fill indexes like tomatoes.viewer.numReviews, or even compound indexes which are on genres and tomatoes.viewer.numReviews. The main difference is that, text indexes do not just follow the exact match of a value against the index structure. They will take in consideration, relevance. How relevant is a key compared to the different entries that are present in that index? In this particular example, the title, cast, and directors are all fields which are going to be indexed based on their text. That means that would be creating an index for text search support. So if we go down here to the notebook and execute this particular query here where our filters specifies that we're looking for a title, Titanic. We can see that we only find the exact match of the movies where the title is Titanic. And if we would change something like the title from capital case to lower case on the title, you might not find absolutely nothing. Because there will not be an exact match for that particular title in our movies, which is fine. That's expected. But we can also do another different type of search. We can specify that we are going to be looking to a text search and we're going to be searching for the term titanic. Once we execute that query, we can see that we can find several different movies, not just one. And not all of them match titanic, either case insensitive, but also, for example, the fact that we have Titan on it. Now, why is that? Text search will take in consideration relevance. And that means that we're going to be looking to things like stemming of the term, case insensitive, diacritics and even stop words. There's a bunch of different other options that like we specified in our search terms that would make this query results smaller or larger depending on the type of fidelity that we want based on the term that we are providing for the search. We're not going to go into too much detail on that. But this is a baseline functionality that MongoDB supports based on a specific set of text indexes that you can specify on a collection. The limitation here is that you can only specify one text search index per collection in MongoDB. All right, cool. l saw some of the different indexes that MongoDB in this particular movies collection has. How can l create one my own if l want to? Let's say, for example, that we have this countries here filled, that l would like to start searching on or matching exactly, or even sorting the results base on the countries that the movie is related with. Now, I could simply define a create index method pathing on an array of two pools. Those two pools will contain the field key that I want, in this case, countries. In what sort of order do I want my index to be sorted? If I would like to have a text field, I could also specify that here or even if it'd be to this field or to the index. That will be the type of index that I'm going to be creating. In this case, I'm going to create a top level root level field, single field index sorted ASCENDING. Once I run the commands, it would tell me back what's the name it was created with following the nomenclature, the fields, and the sorting order. As a recap on this lesson's topics, MongoDB has several different types of indexes. Now, indexes are used to optimize our query performance and the query access patterns that we use in our application. A collection may have several different types of indexes on different fields. Use them wisely, because the more indexes we have, the slower our writes will become. If we are optimizing our read capabilities, we might be putting some penalty in our write ability. That's all I have for you on indexes in movies lesson.
