销售区域细化到区域

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.在此基础上，以树的结构存储，能解决存储空间大的问题，查询性能没有额外压力。