In our current find index, we have products at the root level, and variants under products. We do not have any Nested Conventions enabled. There are about 30Kproducts, each with a few variants (many with only one variant).
List [~70 basic properties]
[~20 basic properties]
We now have a requirement to be able to filter by and facet on up to 10 "technical attributes" at the variant level. We need to be able to filter on technical attribute combinations ... e.g. (TA1 = "A" and TA2 = "B"), and also combinations within a technical attribute, e.g. ((TA1 = "A" or "B") and TA2 = "C")
It seems like the best (only?) way to accomplish this is with Nested Conventions and the NestedTermsFacetExtensions extension.
Modified index models would look like:
List List [rollup of all TechnicalAttributeIndexModels from all of this product's variants] [~70 basic properties]
[~20 basic properties] TechnicalAttributeIndexModel (10 string properties (e.g. TA1, TA2, TA3 ... TA10))
We would add a nested convention, like this:
Conventions.NestedConventions.ForType().Add(p => p.TechnicalAttributes);
("TechnicalAttributes" is the name of the List in ProductIndexModel)
I can see that this setup more than doubles the time to run a full index job (I guess due to all the new "hidden documents" that get created), but what shouldI expect in terms of query performance ? Behind the scenes is this similar to a SQL join that will perform well, or should I be concerned because the index is now much larger ?
Would love to hear from someone with knowledge of how Nested Conventions works under the hood, or with real world experience using it in a solution.