英文:
Entity Relationship Query and Full Text Search
问题
我有一个疑问，只用Elasticsearch或Opensearch是否可以建模如下提案：
我有一个产品索引，我们在市场上供人们进行搜索和购买使用。
今天我有一个新的要求，允许联盟成员对其产品进行调查。
联盟成员是销售真正所有者产品并获得销售佣金的人。
因此，一个拥有1个所有者的产品可以有数百个联盟成员。
今天我们的索引不包含联盟成员，我考虑创建一个单独的索引，因为我们的基础中有许多联盟成员。在这个索引中，我们可以有联盟成员的代码以及他与之关联的产品数组，但从性能角度来看，这似乎不太健康，因为数组会很大。
另一个研究是使用parent-join查询，但我也看到了与之相关的性能问题。
我想知道社区中是否有人对这种具有关联关系并允许全文搜索的建模有任何经验或建议。
我已经考虑到对于这种情况，Elasticsearch可能无法解决整个问题，或者至少它将是涉及另一种技术的解决方案的一部分。
任何意见都将受到欢迎。
英文:
I have a doubt if only with Elasticsearch or Opensearch I can model the proposal below:
I have an index of products, we use it in a marketplace for people to carry out searches and purchases.
Today I have a new requirement which is to allow affiliates to conduct surveys on their products.
Affiliates are people who sell the real owner's product and earn commissions per sale.
Therefore, a product that has 1 owner can have hundreds of affiliates.
Today our index does not contain affiliates and I thought of creating a separate index because we have many affiliates in the base. In this index, we could have the affiliate's code and an array of products he has an affiliation with, but that doesn't seem healthy in terms of performance, as the array would be huge.
Another study was using the parent-join query but I also saw performance issues related to it.
I would like to know from the community if anyone has any experience or suggestions for this modeling that has relationships and allows full text search.
I'm already thinking that for this scenario elasticsearch is not able to solve the whole problem or at least it would be part of a solution that involves another technology.
Any opinion will be welcome.
答案1
得分: 1
以下是翻译好的内容：
还有一个你没有提到的选项，那就是去规范化。你创建一个新的索引的方法可能是正确的，但是不要每个联盟合作伙伴都创建一个带有产品数组的文档，而是应该有每个联盟合作伙伴销售的每个产品都有一个文档。
这样你的文档保持精简，而且查询索引仍然很容易，因为查询将包含一个约束条件，只选择由特定联盟合作伙伴运行调查的文档，然后可以在产品、日期等方面进行其他约束和聚合。
如果一个联盟合作伙伴销售了一个新产品，只需为该联盟合作伙伴/产品对创建一个新的文档。
如果通过联盟合作伙伴销售了某个产品的数量，更新特定联盟合作伙伴/产品文档中的已售数量。
英文:
There's another option you haven't cited, which is denormalization. Your approach of creating a new index for this is probably the right one, but instead of having one document per affiliate with an array of products, that index should have one document per product sold by an affiliate.
That way your documents stay lean and it's still easy to query the index as the query would contain one constraint for selecting only the documents for a given affiliate who runs the survey and then other constraints and or aggregations on products, dates, etc.
If a new product is sold by an affiliate, just create a new document for that affiliate/product pair.
If a quantity of a given product has been sold via an affiliate, update the quantity sold in the specific affiliate/product document.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论