From the official document, we can set up partition fields to speed up the performance when using Online Archive.
The order of fields listed in the path is important in the same way asit is in Compound Indexes . Data in the specified path is partitionedfirst by the value of the first field, and then by the value of thenext field, and so on. Atlas supports queries on the specified fieldsusing the partitions.
For example, suppose you are configuring the online archive for themovies collection in the sample_mflix database. If your archived fieldis the released date field, which you moved to the third position,your first queried field is title, and your second queried field isplot, your partition will look similar to the following:
/title/plot/released Atlas creates partitions first for the titlefield, followed by the plot field, and then the released field. Atlasuses the partitions for queries on the following fields:
the title field,
the title field and the plot field,
the title field and the plot field and the released field.
Atlas can also use the partitions to support a query on the title andreleased fields. However, in this case, Atlas would not be asefficient in supporting the query as it would be if the query were onthe title and plot fields only. Partitions are parsed in order; if aquery omits a particular partition, Atlas is less efficient in makinguse of any partitions that follow that. Since a query on title andreleased omits plot, Atlas uses the title partition more efficientlythan the released partition to support this query.
Here I simplify the situation for asking. I need to query by:
- title(eq)/plot(eq)/released(range)
- title(eq)/released(range)
From the document, title/plot/released support 1. but inefficient to 2.. If I change it to released/title/plot, it seems perfect but violates the ESR rule.
Does Partition Fields need to follow the ESR rule? What is the correct way to solve this requirement? Any deep dive explanations are welcome.