elasticsearch中提示数据结构
Tip data structure in elasticsearch
我需要为不同供应商和不同商店区域的产品创建一个目录。
提供商的一种产品在每个商店区域可以有不同的价格。
在简历中:提供商 - 区域 - 产品
我有大约 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
优点:
- 更新价格和获取商店产品目录的简单方法。
缺点:
- 每个索引中的冗余信息。
- 复杂的信息维护。
- 许多指数
有人可以推荐我选择哪种场景或提供替代方案吗?
在一般的 NoSQL 世界中,尤其是 Elasticsearch,“冗余”不一定(如果有的话)被视为劣势,如 denormalization is key。所以这会支持选项 B,但这不是全部,实用主义应该占上风,因为你知道......这取决于。
另外,索引是少还是多也不一定是问题,如果设计得当,它总是取决于用例以及在数据架构设计上投入了多少努力。使用选项 A,您将拥有 20 个索引,每个索引包含 1.2M 文档,而使用选项 B,您将拥有 ~1K 索引和 20K+ 文档。不确定您的平均文档大小和集群架构,但考虑到您可能 运行ning.
的常见查询,选项 B 的效率似乎略低
您的查询将需要始终对所有索引进行 运行,因此索引越少越好,除非您拥有一个拥有充足资源的庞大集群,但对于只有 25M 的文档,我认为这不是案件。因此,根据您在上面分享的信息,我会先选择选项 A。
另请记住,您的首要任务是让您的用户轻松找到产品,而不是让您更新文档,因此更快的搜索比更快的索引更重要,尤其是当您只是更新时一天一次或两次你的文件。
我需要为不同供应商和不同商店区域的产品创建一个目录。
提供商的一种产品在每个商店区域可以有不同的价格。
在简历中:提供商 - 区域 - 产品
我有大约 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
优点:
- 更新价格和获取商店产品目录的简单方法。
缺点:
- 每个索引中的冗余信息。
- 复杂的信息维护。
- 许多指数
有人可以推荐我选择哪种场景或提供替代方案吗?
在一般的 NoSQL 世界中,尤其是 Elasticsearch,“冗余”不一定(如果有的话)被视为劣势,如 denormalization is key。所以这会支持选项 B,但这不是全部,实用主义应该占上风,因为你知道......这取决于。
另外,索引是少还是多也不一定是问题,如果设计得当,它总是取决于用例以及在数据架构设计上投入了多少努力。使用选项 A,您将拥有 20 个索引,每个索引包含 1.2M 文档,而使用选项 B,您将拥有 ~1K 索引和 20K+ 文档。不确定您的平均文档大小和集群架构,但考虑到您可能 运行ning.
的常见查询,选项 B 的效率似乎略低您的查询将需要始终对所有索引进行 运行,因此索引越少越好,除非您拥有一个拥有充足资源的庞大集群,但对于只有 25M 的文档,我认为这不是案件。因此,根据您在上面分享的信息,我会先选择选项 A。
另请记住,您的首要任务是让您的用户轻松找到产品,而不是让您更新文档,因此更快的搜索比更快的索引更重要,尤其是当您只是更新时一天一次或两次你的文件。