弹性搜索中的Tip数据结构

Question

我需要创建一个不同供应商和不同商铺区的产品目录。

供应商的一个产品在每个商铺区都有不同的价格。

简历:供应商-区域-产品

我有大约20个供应商，他们每个可以有大约50或60个区域最多。每个区域最多可以有20.000种产品。每个区域的产品都是相同的，但价格可能不同。

我对如何存储这些信息有疑问。我需要更新供应商和每个地区每天的价格，但不是所有的地区在同一时间。此外，我需要搜索产品或类别，并只显示其商店的价格。最常见的查询是:列出一个类别的产品与所选区域的价格，或提供产品的信息与所选区域的价格。

我正在考虑不同的场景来存储数据。

场景A-索引提供者X

为每个提供程序创建索引，在嵌套对象中为每个产品和每个区域的价格提供文档。

"id" : 53457,
"categories": [5563,5686],
"description": "bla bla bla",
....,
"zones": [ {"id": 259, "price": 4.55}, {"id": 260, "price": 4.45}]

优势：

• 指数不多。
• 无冗余信息存储
• 信息维护更容易。

缺点：

• 更新和价格搜索更复杂，可能更低的性能。

场景B-提供者区域X索引

为每个区域创建一个索引。

"id" : 53457,
"categories": [5563,5686],
"description": "bla bla bla",
....,
"price": 4.55

优势：

• 更新价格和获取商店产品目录的简单方法。

缺点：

• 每个索引中的红色信息。
• 复杂的信息维护。
• 多项指标

有人能推荐我选择哪一种方案或提出另一种方案吗？

Answer 1

在NoSQL世界中，特别是在Elasticsearch中，“冗余”不一定被认为是去正规化是关键的劣势。所以这将有利于备选方案B，但这并不是全部，实用主义应该占上风，因为你知道.那得看情况。

此外，是否很少或多个索引也不一定是一个问题，如果设计正确，它总是取决于用例和在数据架构设计上投入了多少精力。对于选项A，您将有20个索引，每个索引包含120万个文档，而对于选项B，则有~1K索引和20K+文档。不确定您的平均文档大小和集群体系结构，但考虑到您可能运行的常规查询，选项B的效率似乎略低一些。

您的查询将需要一直在所有索引上运行，因此，除非您有一个拥有充足资源的庞大集群，否则索引越少越好，但对于2500万个文档，我认为并非如此。因此，考虑到你在上面分享的信息，我会先选择A。

还请记住，您的首要任务是让用户更容易地找到产品，而不是更新文档，所以快速搜索比快速索引更重要，特别是如果您每天只更新一两次文档。