Chapter 3: Faceted Search - Order of Operations Confusion

[Dennis_Uhrmacher]

I’m trying to do the second ticket in chapter 3 and I am confused. It seems like the previous video introduced aggregation, stated a few, and then the ticket is for something 10 steps beyond what the lecture covered. I think the course would benefit from one more lecture being put before this that covers order of operations in an aggregation pipeline. I think it would be a much more natural lead-up to this ticket item than the leap that occurs now.

I don’t know how to determine what order the aggregates go in for the ticket. I could just keep moving them around until I get lucky, but I’d rather learn how to determine the order for myself. Is there any resource out there that explains this? I tried Googling and all I found was lists of the aggregates, which doesn’t help in this case.

[Yilmaz_Durmaz (Yılmaz Durmaz)]

did you check this page? : $facet (aggregation) — MongoDB Manual

in a normal aggregation operation, you will end up with only 1 operation result from a single collection (or collections with “$lookup”)

with “$facet” you can have multiple operation results combined. but since the result is still a single object, you may extend your aggregation for more operations.

this is confusing since you can “facet” at the beginning, at the end, or anywhere. the thing is you will end up with a new structure after a “facet”, formed by as many fields as your pipelines in it.

what you need to ask yourself is “which data do I need for facet pipeline” so to narrow down documents before that stage, and “what else do I need after facet” to further process data.

In these M220X courses, we need to narrow down “runtime”, “rating” and “movies” fields by search parameters yet we don’t need anything after “facet” stage so you can guess where should it be.

A worst-case scenario we could write would be to use the “facet” stage first, but that would also be the last because it will give those 3 fields we want. to use search parameters, we would have to embed each of the previous steps (match,sort,skip,limit) into “runtime”, “rating” and “movies” in the “facet”. after all, each stage in “facet” are themselves fully qualified aggregations.

in this worst case, each “facet” stage would use the full collection 3 times so your query will take 3 times as long.

[Dennis_Uhrmacher]

So facet goes last, but I’m still confused on how to order the other 4 stages before it.

Doesn’t seem to matter what order I try, I get “Expected 3 But was 0” from the unit test.

[Yilmaz_Durmaz (Yılmaz Durmaz)]

you can limit only the last result unless you have evil plans The same goes for skip, but you would prefer skipping before limiting.

matching and sorting are independent; sort before match or match before sort, same for the result. but not for the performance of the query. now guess which order would be faster

I think there is another course about these performance gains. check other available courses.

[Dennis_Uhrmacher]

Ohhh, sweet. It passed now.

I was taking it as you had to limit the matched results and then do the sorting and paging. I see the error in my logic now. I’m going to write that down for future use.

Thank you!!