大佬们咨询下你们公司的商品信息存储方案.

[zgscwjm]

目前我们公司存在基础商品大约 300w 个商品.
存在 1k 个客户,每个客户在这 300w 的基础商品里面选大约 200w 的商品.
同一个品,每个客户有不同的价格,上下架状态,库存.
需要支持客户按价格和上下架状态,商品基础信息进行查询.(商品名称要涉及分词)
商品基础信息,上下架状态,价格,库存 日常 会有变动.但是量不会特别大,每天大约 10w 左右变动
大促活动的时候,可能会有大量的变动信息.
需要支持高效写入和高并发查询.目前是用 es 进行支持的.但是当大促的时候,es 写入性能较慢.
请问下各位大佬,还有什么好的技术方案吗?

[wzwb]

ParadeDB

[wangbin11]

我没登录账号逛 v 站，都的登录上来喷两句，你们的缓存呢中间件呢，全靠 es 撑着啊，es 的集群都多大了

[MADBOB]

我比较好奇...是做啥的...300w 个商品？ 1k 个客户看着也不像零售呀

[zgscwjm]

@MADBOB toB

[lazyfighter]

mark es 写入慢跟大促有啥关系，qps 高了，导致写入性能低， 低多少呢

[zgscwjm]

@wangbin11 缓存这些我理解在这里的场景使用有限吧.

[zgscwjm]

@lazyfighter 大促的时候,商品的基础价格,返点有变化,通过 spark 计算后,全量同步到 es 上,现在写入的过程中,会把 es 集群的 cpu.io 打满.导致其他服务查询 es 的时候超时

[31415926535x]

一个索引的话拆分索引试试，大促要扩机器
数据变更接受多少的延迟呢，写入可以走 mq 慢慢写么，或者改成批量写入操作
查询的数据需要精确度很高么，金额之类的如果可以忽略个位数，应该可以减少部分写入操作

[yn1024]

1 、引入 kafka ，把写入变得平滑一些，防止 ES 挂掉（但可能牺牲写入速度）
2 、加一层 redis ，应付高并发查询
3 、把数据（商品信息）做分片，多加几个 ES 实例，不同实例处理不同分片，上面加聚合层

[tidaizhe]

看起来像是做商超的

[zgscwjm]

@31415926535x 多个分片,就是硬件资源有限,拆分索引会冗余存储商品信息.商品的基础变更会被放大.现在是直接用 spark 往 es bluk 写入,会把机器拖死,已经调整了 es 的 refresh_interval,等参数.商品价格,折扣对精度有要求.引入 kafka/mq 中间件这些的之前有考虑过,可以缓解 IO,但是更多的是想在结构上进行调整.

[me1onsoda]

300w 这个数据量很大吗，需要考虑那么多吗

[SorcererXW]

10w/天的数据量，qps 才 1 ，活动期间多个数量级算是 10qps ，不太能理解 es 为什么会消费不过来

[zgscwjm]

@me1onsoda 300w 乘以 1000 客户数

[zgscwjm]

@SorcererXW 大促 100w 的商品变动,要乘以 1000 的客户数.

[headwindx]

@zgscwjm 用户也不会同时查看 300w 个商品信息吧？

[zgscwjm]

@headwindx 会从中根据各种属性进行筛选

[wangbin11]

@zgscwjm 参考 9 楼说的很清楚了

[lazyfighter]

返点折扣是以商家维度，还是商品维度，感觉是两个场景：
1 根据商家设置返点以及折扣
2 不同商家不同商品设置不同返点以及折扣
按照你的描述共计 300w 商品， 场景猜测：
大概率是商家维度设置整体的商品返点以及折扣，同时可以给商家配置特殊商品折扣。
如果是这种场景的话， 商家维度设置整体的商品返点以及折扣这个写入场景非常少，建立特殊的表存储，其它在查询的时候按照折扣以及返点实时计算筛选条件进行查询

[vivisidea]

300w 个商品算很少了吧，es 慢是多慢呢？目前 es 的集群是什么配置？多少个节点？ SSD 上了么？

能用硬件解决的，就不折腾了。。说不定比人工还便宜

[zgscwjm]

@vivisidea 300w 要乘以 1000 个客户哦,就是 30 亿数据,全量同步的时候,cpu.io 全部打满.大约 40 分钟的时间内 通过 id 查询 耗时在 5 秒之上.3 个节点.ssd 上了哦,就是没有资源了.

[zzmark06]

300w 个商品，1000 个客户，sku 总计 30 亿以上，你比 amazon 规模还大。
淘宝十几年，估计也就这数量级吧
都这规模了，要不去硅谷挖几个人吧
哈哈哈哈