在 Elasticsearch 中建模父/子关系（产品/产品变体）

Question

打破我对使用 ES（或 Solr）建模 productvariants 的想法

考虑（人为的例子）：

• 不同的产品（比如 T 恤）
• 每个产品都有一组属性（productid、name、desc、brand、color、popularity）
• 每个产品都有一组带有属性的 productvariants（productvariantid（productid++size 的组合）、productid、大小、可用性、价格）

这似乎是 product 和 productvariant 之间的标准父/子关系。所以我想在 ES 中像那样建模。

我希望能够执行以下操作：

• A. 查询 productvariants（并返回所有属性）。无需返回 product-properties，productvariant 属性就足够了。

• B. 每个用户查询都受到约束，因此每个产品最多有 1 个 productvariant 匹配（在上面的示例中，这意味着我们对 productvariant.size 进行约束）

• C. 过滤价格。

• D. 过滤产品的一些属性

• E、按价订购

• F. 按产品属性排序，例如受欢迎程度，或两者的组合。

• G. productvariant.price 的方面

• H. 产品（父）的多个属性的方面

使用父/子文档和has_parentES执行此操作：AE + G是可能的。

但是，F和H呢？我已经研究_scope了方面（虽然我承认我没有 100% 把握可能性）和所有其他想到的东西，但我没有看到一个明显的解决方案来显示产品属性的方面并且能够与 一起按它们排序has_parent。

我已经尝试了其他东西（在纸上） - has_child -> 没有运气需要返回变体信息 - 嵌入式文档（产品内部的变体）并返回带有所有变体的整个产品。只是感觉很笨拙。此外，我很确定我不能以这种方式对价格进行分面/订购。

非常感谢帮助

Answer 1

我把头撞在墙上很长一段时间，试图让类似的计划发挥作用。我的方案是产品/供应商关系（多个供应商销售的单一产品，可能有不同的描述/价格/可用性）。

ES 中的父-> 子映射现在不是很健壮或易于使用。即使你得到了一些工作，你也会很快遇到边缘情况，这实际上是不可能的，因为 ES 不支持它。

我认为最好的办法是自己管理父-> 子映射并将文档存储在它们自己的索引中。产品有一个 ID，然后将其作为 Product_ID 存储在 ProductVariant 文档中。无论如何，这实际上是 ES 在内部存储父-> 子关系的方式。

在实践中，您查询“顶级”索引（产品），然后使用 Product_ID 字段上的过滤器对 ProductVariant 的索引执行第二次查询。

维护起来有点麻烦，但更灵活。至少在 ES 获得更好的 Parent->Child 能力之前