销售区域细化到行政区域
1.现状:
商品按城市划分运营,销售区域精确到行政区,随着city数量越来越多,商品管理需要在不同城市重复上架,任务量很大。
2.目标:
支持全国统一管理,销售区域还是精确到行政区。
3.解决方案:
销售区域设计:
字段名 | 数据类型 | 备注 | 例子 |
---|---|---|---|
id | integer | 自增 | 123456 |
code | integer | 六位数字 | 420102 |
name | varchar(255) | 地址名称 | 湖北省武汉市江岸区二七街道 |
用户地址设计:
四级地址(0-42-4201-420102) 必须需要四级地址
技术实现:
查询语句:
post http://localhost:9202/promotionsku/promotionsku/_search
{
"query": {
"bool": {
"must": [
{
"terms": {
"canSellAreaIds": [
0,
42,
4201,
420102
]
}
}
]
}
}
}
存储结构
"name": "可口可乐500ml(1*24)",
"brandId": 3688,
"brandName": "可口可乐",
"productType": 2,
"saleMode": 0,
"canSellAreaIds": [
10000,
420102,
420102,
420103,
420104,
420105,
420106,
420107,
420111,
420112,
420113,
420114,
420115,
420116,
420117
],
区域参照表:
code | name |
---|---|
0 | 全国 |
10 | 北京市 |
42 | 湖北省 |
4201 | 武汉市 |
420102 | 江岸区 |
性能评估:
使用四级地址,树状存贮结构,数据量和之前有cityId的时候一致,与现状比较不存在额外困难。
极端测试:
配置:
环境:test环境
区域:402
商品数量:1W
每个商品销售区域:5k
销售区域类型:Long
只根据saleAreaId查询,初次最大耗时282ms,正常是140ms,访问多次只有10-20ms:
实验数据
1.初次访问多次实验最大耗时
2.多次访问后Es自身缓存效果
遇到的问题:
1.saleAreaId设置为1w个的时候,bulkIndex,报错requestBody too large json 解析失败,本次实验减少到5k,这个问题可以通过减少批量数解决。
扩展性
区域
操作 | 区域未满 | 区域满 |
---|---|---|
增 | 没影响 | 默认支持,如果需要不支持,运营手动修改成区域。 |
删 | 没影响 | 没影响 |
改 | 没影响 | 没影响 |
难点:
用户四级地址能否准确获取?
现有商家肯定支持四级地址,如果不全需要强制维护。
4.结论
1.销售区域全量存储,对于ES性能影响很小,存储空间大一些,但总量有限,没有压力。
2.在此基础上,以树的结构存储,能解决存储空间大的问题,查询性能没有额外压力。