商品上架-sku在es中存储模型分析

为什么要使用es搜索引擎？
请点击
es简介

sku在es中存储模型分析

在商品里搜索商品时，
1.可以通过三级分类作为检索条件
2.也可以通过sku_title来进行检索

3.也可以通过spu规则来进行检索，因为所有的sku是共享spu的规格的

4.也可通过销量，价格等等来作为检索条件

所以我们在保存到es中的映射中应该包含
skuId，sku_title，spuId，price，saleCount以及一些规格属性等等信息

第一种存储方式

文档的会稍微大一些，如果有100w个商品，每个文档冗余的大小为2KB（规格属性信息）,那么es至少需要冗余100w*2KB = 2000MB=2G的数据,只需要在es服务器中加一个内存条就好了，就算是1000w个商品也是没关系的，加个20G的内存条就好了，虽然占用的空间大，但是效率也是很高的（后边会进行解释）。
文档字段：{
skuid:1
spuId:11
sku_title:Apple 13
price:998
saleCount:99
attrs:[
{屏幕尺寸：5寸},
{CPU:高通886},
{分辨率：全高清}
}

第二种存储方式

sku索引{skuId:1,spuId:11,其他信息}
attr索引{spuId:xx,attrs:{ {屏幕尺寸：5寸}，{CPU:高通886}，{分辨率：全高清} 等其他属性及属性值}
优点：sku文档中只存他自己的信息，不像第一种存储方式那样，每个sku文档中都会冗余一些规则参数。用一个attr索引去保存spu下需要被共享的属性及属性值。
检索步骤：先检索出sku文档，根据sku文档中的spuId去attr索引下查找它的属性，这样既满足了好检索，也满足了不冗余。
致命的问题：

这里边的属性及属性值是根据我们检索到的所有sku进行一个聚合操作进行动态计算的。
假设场景：搜索“小米” ；会搜索出很多的sku_title中有小米的，比如粮食，手机，电器等等等，规则参数中有所有spu聚合的规则参数，如下图，品牌中不光有小米手机对应的属性值，还有吃的小米的属性值

假设搜索小米，
有10000个sku，10000个sku总共对应4000个spu，
由于规格参数时进行动态获取的，并且在这里我们将sku和规格参数进行了分开存储，所在在聚合所有的spu的规格参数时，必须查4000个spu的属性规格参数，并进行聚合。
es Client查询4000个spu的属性及规格参数的时候，必须传一个数组，包含4000个spuId(long类型）,一个long型占8个字节，4000个spu就是32000字节=32Kb,也就时说一次请求就会传32Kb的数据
万级并发下：
32Kb10000=320Mb
百万并发下：
32Kb1000000=32G
这么大的数据直接发送到服务器，我去，，，，不说网络拥堵，，服务器也根本处理不过来啊！

总结：

但是在第一种存储方式中，10000个sku的属性及规格参数，都被冗余的存储在sku文档中，所以直接对sku文档中冗余的数据进行一个聚合就好，省去了根据spuId去查属性及属性值的这个操作，也不会造成那么严重的问题。

标签：sku,spuId,上架,spu,文档,es,属性
来源： https://blog.csdn.net/daniu_weilai/article/details/120394142