Choose between object, nested, flattened and denormalization for seller offers.
- Product → offers
- One-offer scope
- Correlated predicates
Choose between object, nested, flattened and denormalization for seller offers.
The course targets Elasticsearch 9.4.3. Exercise examples use the public products dataset; other requests illustrate separate teaching indices and may require setup or privileges unavailable in the trainer. Responses are shortened fragments; scores may vary. Check deployment and license requirements for advanced features.
When associations disappear
A product has seller A at 100 and seller B at 50. An ordinary object array does not preserve the association between each seller and price for independent field matching. seller=A and price<60 can match the product without a qualifying offer. Requiring both conditions on one offer is a modeling requirement, not just Boolean syntax.
Check your understandingThe cost of nested
Nested stores objects as separate hidden documents and requires nested-aware queries, aggregations and sorting. Updating part of a large root document can reindex its nested block. Object count and update frequency matter. For independent frequently changing offers, compare a separate offer index with the product-document approach.
Check your understandingDenormalization and arbitrary keys
Denormalization copies frequently used data into a document and reduces query-time joins. Renaming a brand then affects many products. Flattened supports arbitrary keys and simple value matching, but does not replace typed numeric fields. Parent-child needs co-location and adds join cost. Unbounded user keys should not each become a new mapped field.
Offers retain seller-price associations within a product.
{
"mappings": {
"properties": {
"name": {
"type": "text"
},
"offers": {
"type": "nested",
"properties": {
"seller": {
"type": "keyword"
},
"price": {
"type": "double"
}
}
}
}
}
}How to read this result
Offers retain seller-price associations within a product.
Catalog reasoning example
Compare embedding all offers in a product with storing each offer independently and grouping search hits by product. The first makes correlated predicates and complete cards convenient; the second reduces update granularity but complicates grouping and counts. Field count alone cannot decide. Consider update rate, array size, result requirements and the cost of rebuilding a product document.
Check your understandingCheck your understanding
Answer before expanding each explanation.
1. Why can seller=A AND price<60 be wrong?
With object mapping the values can belong to different array elements.
2. When is nested needed?
When several predicates must apply to one array object.
3. Is a nested update cheap?
No, block reindexing can be expensive.
4. Why are arbitrary keys risky?
They can cause mapping explosion and metadata growth.
5. Why denormalize?
To optimize reads while accepting update propagation costs.
Module case study: Data modeling and analysis
Two sellers offer one product at different prices. The catalog needs Russian name search, exact brands and a particular seller’s price filter. Propose a mapping and explain why one text field and an object array are insufficient.
Assessment criteria
Use text and keyword, inspect language analysis with _analyze, and preserve seller-price association with nested or separate documents.
Key takeaways
- With object mapping the values can belong to different array elements.
- When several predicates must apply to one array object.
- No, block reindexing can be expensive.
- They can cause mapping explosion and metadata growth.
- To optimize reads while accepting update propagation costs.
Official reference
Ready to put this into practice?
Confirm reading to save your place. Reading and exercise progress are tracked separately in this browser using your guest cookie.