文章目录
- 一，Elasticsearch在谷粒商城中的应用
- 1，商城的商品检索
- 2，日志检索
- 二，谷粒商城ES的商品索引mapping如何设计
- 1，商品索引product的mapping
- 冗余 SPU 信息的原因
- 第一种方案的优缺点：
- 优点：
- 缺点：
- 第二种方案（SPU 单独存储）的优缺点
- 优点：
- 缺点：
- 选择第一种方案的理由
- 2，mapping设计核心点
- 2.1 index: false
- 2.2 `doc_values: false`
- 3. 唯一的全文检索属性
- 4，总结
一，Elasticsearch在谷粒商城中的应用
这一节的内容非常重要，讲述了ES在商城中如何使用，从大的方面来说，主要有两大场景：
- 商城的商品检索
- 系统日志检索
1，商城的商品检索
第一种检索：根据三级分类检索。
鼠标移到左侧的三级分类，右侧列出更详细的分类信息，点击其中一个分类，比如办公桌，前端页面会向后台发出请求，商品服务接受到请求后会从ES中根据分类检索到这个分类下的SPU，并返回给前端展示。
第二种检索：根据SKU标题检索。
如下图，输入关键词公主笔记本进行搜索，前端页面发出请求，后端接收到请求后，根据关键词在ES中进行全文搜索，并整理搜索到的结果的属性值，进行分类汇总，把整理过的属性值(对应下图第一部分)和搜索到的SPU返回给前端进行展示(对应下图第二部分)。
注意，第一部分是根据搜索结果的属性值动态分类汇总而来。
2，日志检索
有过较大项目微服务开发经验的同学，对日志检索应该非常熟悉。对于排查测试和开发环境中的问题来说，日志检索必不可少。
二，谷粒商城ES的商品索引mapping如何设计
1，商品索引product的mapping
执行如下请求，创建商品索引product。
PUT product
{
"mappings": {
"properties": {
"skuId": {
"type": "long"
},
"spuId": {
"type": "keyword"
},
"skuTitle": {
"type": "text",
"analyzer": "ik_smart"
},
"skuPrice": {
"type": "keyword"
},
"skuImg": {
"type": "keyword",
"index": false,
"doc_values": false
},
"saleCount": {
"type": "long"
},
"hasStock": {
"type": "boolean"
},
"hotScore": {
"type": "long"
},
"brandId": {
"type": "long"
},
"catalogId": {
"type": "long"
},
"brandName": {
"type": "keyword",
"index": false,
"doc_values": false
},
"brandImg": {
"type": "keyword",
"index": false,
"doc_values": false
},
"catalogName": {
"type": "keyword",
"index": false,
"doc_values": false
},
"attrs": {
"type": "nested",
"properties": {
"attrId": {
"type": "long"
},
"attrName": {
"type": "keyword",
"index": false,
"doc_values": false
},
"attrValue": {
"type": "keyword"
}
}
}
}
}
}
设计商品mapping结构时，有两种方案：
- 第一种方案是每一个sku文档都冗余spu信息
- 另一种方案是把spu信息单独保存，检索时通过spuId关联sku信息。
我们最终采用的是第一种方案，理论依据就是用空间换时间，追求检索的高效率。具体分析如下。
冗余 SPU 信息的原因
-
查询性能:
- 直接在 SKU 文档中包含 SPU 的关键信息（如
spuId）可以避免在查询时进行额外的关联操作。 - 这样做可以减少对其他索引或文档的访问，从而加快查询速度。
- 直接在 SKU 文档中包含 SPU 的关键信息（如
-
可扩展性:
- 当 SKU 和 SPU 的数量都非常大时，减少索引之间的依赖关系可以提高系统的整体性能。
- 如果 SPU 信息被频繁地用于 SKU 查询，那么将它们内联在 SKU 记录中可以简化查询逻辑。
第一种方案的优缺点：
优点：
- 查询效率：直接从 SKU 文档获取所有所需信息，无需进行额外的关联查询。
- 易于维护：简化了数据模型和查询逻辑。
缺点：
- 存储开销：每个 SKU 都会携带完整的 SPU 信息，可能会增加存储空间的需求。
- 数据更新：如果 SPU 信息发生变化，需要更新所有相关 SKU 的记录以保持一致性。
第二种方案（SPU 单独存储）的优缺点
优点：
- 存储效率：避免了冗余数据，节省存储空间。
- 数据管理：更容易管理和更新 SPU 数据，只需在一个地方更新即可。
缺点：
- 查询复杂度：需要额外的关联查询来获取完整的 SPU 信息，这可能导致查询性能下降。
选择第一种方案的理由
- 性能优先：如果你的应用程序需要非常快速的响应时间，并且查询 SKU 时经常需要 SPU 的相关信息，那么将 SPU 信息内联到 SKU 记录中可以显著提高性能。
- 简单性：对于复杂的查询，内联 SPU 信息可以减少开发和维护的成本。
2，mapping设计核心点
这个映射定义中的几个核心点如下：
2.1 index: false
当一个字段设置为 index: false 时，意味着该字段不会被索引，因此无法进行基于该字段的搜索。例如，在这个映射中，skuImg, brandName, brandImg, catalogName, 和 attrs.attrName 字段都被设置为 index: false。这意味着这些字段将不参与全文检索，也无法通过这些字段进行过滤或排序。
2.2 doc_values: false
doc_values 是一个字段级别的设置，它控制是否存储该字段的值以便于排序、聚合或脚本使用。当 doc_values: false 时，表示该字段不会存储任何文档级别的值，也就意味着不能基于这些字段进行排序或聚合。
3. 唯一的全文检索属性
在这个映射中，唯一被标记为全文检索的属性是 skuTitle，其类型为 text 并且使用了 ik_smart 分词器。这意味着 skuTitle 字段支持全文检索功能，并且在搜索时会使用 ik_smart 分词器进行分词处理，以实现更智能的中文搜索结果。
4，总结
-
index: false的目的:- 减少存储开销：不索引这些字段可以节省存储空间。
- 提高性能：不需要维护索引，可以提高写入性能。
- 简化查询：不需要考虑这些字段在查询中的使用。
-
doc_values: false的目的:- 减少存储开销：不存储文档级别的值可以进一步减少存储空间的需求。
- 提高性能：不需要维护文档级别的值，可以提高写入性能。
- 限制使用场景：不能基于这些字段进行排序或聚合。
-
全文检索属性:
skuTitle被设计成全文检索属性，允许用户基于产品标题进行搜索。- 使用
ik_smart分词器，可以提供更精细的中文分词能力，从而提高搜索质量。
结合这些特点，可以推得出以下几点：
-
设计意图:
- 映射的设计倾向于优化性能，以空间换时间。
- 重点放在了
skuTitle上，因为这是用户最有可能用来搜索产品的字段。 - 其他字段主要用于参考或显示用途，而不是作为查询条件。
-
应用场景:
- 适用于那些需要高效搜索的产品目录系统，其中产品标题是最主要的搜索依据。
- 对于其他字段的查询需求较低。
